Tested the issue on android and able to reproduce this issue

Steps to reproduce:
--------------------------
1. Disabled chrome and observed version as 61.0.3163.98
2. Installed sample .apk file attached 
3. Opened Sample webview and selected font color, Background >> Entered some text, observed both background and font color
4. Clicked enter, selected indent -- Entered some text, observed both background and font color
5. Clicked enter, selected outdent and observed background color missing.

Webview version:
61.0.3163.98, 66.0.3359.106 and 68.0.3440.85

OS:
Android 8.0 

Android device:
Pixel 2 

This issue is seen from older builds. Hence marking this issue as Non-Regression for further inputs from dev team.

Please navigate to below link for log's  --
go/chrome-androidlogs/871196

Thanks!

I'm afraid we (the Blink team) can't provide support for third party android applications. Unless there is a way to reproduce this in chrome there really isn't much we can do about it.

Closing this in favor of the original buganizer issue, so we can keep everything in one place.

---

eae@ does your team have a device to test the repro app (app-debug.apk) provided on http://b/78665516? If not, what does your team need to reproduce this (and verify if this is your bug)?

Reopening this because I can reproduce this in desktop in Chrome (and therefore it's not a WebView bug).

Please see the attached zip. Repro steps:
1. $ unzip -d somedir/ repro-lfiles.zip
2. $ cd somedir/repro-in-web/
3. $ python -m SimpleHTTPServer
4. Open chrome to http://127.0.0.1:8000/
5. Click the first line of the iframe (this is to define the focus for the next operations)
6. Click "font color" and "background" buttons
7. Click the 1st line of the iframe. Input 1 line of text. Observe text is red font with green background. Press enter to go to the next line.
8. Click the "indent" button. Type a second line of text in the iframe. This should be red, green, and indented. Press enter to go to the next line.
9. Click the "outdent" button. Type a third line of text in the iframe. Observe this text is red and outdented, but has mysteriously lost the green background.

Samsung believes the Chrome behavior is a bug. Can you confirm? If it's intended, can you explain why we lose the green background? Please see http://b/78665516 and see pixel_video_sampleApk.mp4 for an example repro (this is done with their sample app, but the steps are similar to iframe-based page I wrote).

Deleted: repro-files.zip 2.2 KB

repro-files.zip 2.2 KB Download

ntfschr: We'd need a way to reproduce this in Chrome (preferably), or in a vanilla web view.

eae@ the steps above should work for Desktop Chrome. Which step blocks you from reproducing? Perhaps I can find an alternate step.

The javascript uses execCommand, so maybe this is a better component?

Basic summary: `execCommand('outdent', false)` clears the background color (previously set by `execCommand('backColor', false, '#00FF00')`). But, this basic summary is certainly an oversimplification: please see my full repro steps (or, see the video) to better understand.

I attempt to reproduce this on desktop, M68-stable and M70-canary with https://jsfiddle.net/rhvdm8xz/40/

ntfschr@, could you provide exact step to reproduce?

Thanks for putting together jsfiddle. I can still repro with my instructions on M68 (google workstation) and M67 (google macbook, 67.0.3396.99). Here's a slight simplification:

1. Click in the box
2. Click forecolor, backcolor
3. Click back in the box, type anything, press enter
4. Click indent
5. Click back in the box, type anything, press enter
6. Click outdent
7. Type anything. Observe.

I've attached screenshots to demonstrate what it looks like. This does not repro for all combinations of pressing the buttons, but there are probably more ways to repro than this exact sequence.

I'm happy to repro in person for xiaochengh@ if this bug is blocked.

Deleted: AfterStep3.png 17.2 KB

	AfterStep3.png 17.2 KB View Download

Deleted: AfterStep5.png 19.5 KB

	AfterStep5.png 19.5 KB View Download

Deleted: AfterStep7.png 21.1 KB

	AfterStep7.png 21.1 KB View Download

I confirmed this on a local (unmodified) chrome desktop build (70.0.3509.0).

ntfschr@, thanks for providing repro steps. I can reproduce this.

It seems DeleteSelectionCommand::CalculateTypingStyleAfterDelete() failed to pick up background color from previous paragraph. Actually, we calculate typing style at position, EditingStyle::PrepareToApplyAt().