I can reproduce this.

These look like droppings due to newline paint invalidation failing to
include newlines.

I can still repro on 56.0.2924.10 (Official Build) dev (64-bit).

Can't repro on Mac 57.0.2938.0 (Official Build) canary (64-bit) or Win 

Can repro on Win7 57.0.2938.0 (Official Build) canary (64-bit) but it's harder to see, it's just a one or two pixel narrow band where on Linux it's a larger chunk.

Probably dependent on font metrics, rather than actual platform code difference.

 Issue 669178  has been merged into this issue.

 Issue 668672  has been merged into this issue.

See duped bugs above for additional test cases.

The original repro steps for https://codereview.chromium.org/1907213002/ #16 in that change still repro in Linux 56.0.2924.10 (Official Build) dev though it's quite finicky, the widths must be just right to show the issue.

Paint flashing appears to show that when we select/deselect we're not invalidating inclusive of padding on the 'div.message-text' element that contains the 'cr-linkified-text' Polymer element that contains the actual message.

Haven't been able to easily create a reduced test case yet.

Reduced test case attached. We do see an under-invalidation where the selection highlight incorrectly remains. This case seems specific to padding in combination with 'white-space: pre-wrap' but there could be others.

Deleted: selection-preformatted.html 1.1 KB

selection-preformatted.html 1.1 KB View Download

Picture illustrating situation attached. Newline highlight probably extends outside of RootInlineBox whose bounds are used for the paint invalidation and visual rect. Potential solutions:

1. extend paint invalidation/visual rect bounds to ensure they include the highlight (work has been done to do this, but this case must have been overlooked)
2. don't use a newline wrap highlight here (need to understand 'white-space: pre-wrap' and what it produces w.r.t. layout tree better)

This case is funny as there's a white space char already at the end of the line, but our plan has been that if the line wraps we should show a newline, and it does wrap even though the final char is whitespace.

Deleted: selection.png 62.9 KB

	selection.png 62.9 KB View Download

Notes on another repro case, I can repro on Windows but not Linux, due to difference in where text wraps for whatever reason:

https://bugs.chromium.org/p/chromium/issues/detail?id=596190#c5
- resize the window large enough so "having" is the last word on the first line
and there's some space to the right of it
- then it leaves a trail on that line when you select across it and deselect
- this is on windows at 2x5x dsf for me

Need to confirm it's the same 'white-space: pre-wrap' issue as reduced test case above, else should file another bug to track this one.

Another case:

https://twitter.com/dog_rates/status/833722901757046785

Select the tweet's text and then click in the text to remove it. Left behind trail on right side of "aerodynamic."

You have to select from the 1st to 3rd row to repro. 1st and 2nd doesn't.

Windows 10. Not high dpi. Stable 56.0.2924.87 and canary 58.0.3018.0. Incognito is same.

Unassigning self from work that I do not expect to be able to get to soon.

Another example on TOT.

1. Open https://chromium-review.googlesource.com/c/chromium/src/+/692999#message-56affcc760b952262564fb159963fa23b35d89ff
2. Select the line "Are you sure this swizzling is necessary?  When BGRA is not supported as a texture format, perhaps it " and the next line.
3. Unselect it all.

Line ending stays selects on that line.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I was unable to repro using c#9 and c#15, on Mac and Linux, using Chrome 71.0.3578.53. But this seems like a finicky bug, so I'm leaving this open but available.