Able to reproduce the issue on windows 7,Ubuntu 14.04,Mac 10.11.4 using chrome version 54.0.2840.71 and canary 56.0.2896.0.

This is non regression issue as this is observed from M37 ( 37.0.1986.0) to latest canary. Unbale to test this issue from M30 to M36 as we observed Blue highlighted screen in the mentioned site. Hence marking it as Untriaged .

Please find the attached screencast of M36 & stable builds.

Thanks,

Deleted: 657325-M36.mp4 566 KB

	657325-M36.mp4 566 KB View Download

Deleted: 657325-Stable.mp4 523 KB

	657325-Stable.mp4 523 KB View Download

jmukthavaram@ the bug reported is not that the selection order seems very wrong, it's that the text rendering has the top few pixels cut off after the selection is cleared.

I cannot reproduce that problem on Linux M55 or on Win 7. slambera@, could you please try Chrome Canary or Beta and see if the problem persists?

The problem is clearly an incorrect bounding rect for the text, because in the reporter's video the selection is also shorter than it should be. Then we do not invalidate the text area correctly when the selection is cleared. There has been a lot of churn in this area of the code so there is a good chance that we have just fixed it.

i have downloaded some portable 56.0.2915.0 and it looks same :| but i have to drag the cursor approximately in the middle of that selecting line - if i go under, it fixes

Deleted: selection.png 15.7 KB

	selection.png 15.7 KB View Download

The selection rect of the second line is clipped to avoid overlapping with the (potential) selection rect of the first line. That clipping should probably only apply to the selection background and not the text itself.

This isn't limited to woff fonts but in this case given the ratio between the decent and the line height it is a lot more noticeable.

Re comment #5, thanks for the info. The solution is probably to use the non-clipped selection rect for invalidation, because the bug is with us never invalidating and redrawing the clipped out text.

Is this a regression? Has it been bisected?

I will look.

Somewhat reduced test case attached.

Deleted: test.html 895 bytes

test.html 895 bytes View Download

Deleted: candara_regular.woff2 39.3 KB

candara_regular.woff2 39.3 KB Download

Re: #8 on bisecting, #1 notes "...This is non regression issue as this is observed from M37 ( 37.0.1986.0) to latest canary."

I've tried bisecting back to M43 and what I see is that the behavior is different if you go back far enough, for example Linux 46.0.2486.0 looks like attached, vs ToT sample, also attached.

It looks to me like the selection rect is positioned wrong (it's too low), and with the more recent build behavior, it's possible that it's painting the top of the text but that when inverted it's painting white on white and so not visible. It's not clear yet to me that it's an invalidation rect bug.

The test case is a bit crazy, using :first-line, justify-content, display: flex, box-sizing: border-box, and line-height: 1.

Deleted: 46_0_2486_0.png 6.2 KB

	46_0_2486_0.png 6.2 KB View Download

Deleted: 56_0_2924_3.png 5.1 KB

	56_0_2924_3.png 5.1 KB View Download

Further test reduction using same font file as in c#10. +cbiesinger as this requires display: flex, in case he knows of related existing flexbox bugs. Though the root issue here is more likely selection/clipping rect related.

Deleted: selection-no-clip-text.html 461 bytes

selection-no-clip-text.html 461 bytes View Download

Hacking the text style to paint with normal text color rather than selected text color, and/or hacking the selection highlight rect to encompass the full text region, I can confirm that the issue is that the selection highlight rect y-pos is too low due to the large first-line, and though we are properly painting and invalidating the top of the second line of text, it's being painted in the inverted white color, and so not visible.

This is an evolution of what's discussed in c#5 and c#6, however to be clear, the text is not being explicitly clipped, it's just not visible as it's painted in a color that's invisible when the selection highlight doesn't cover it.

The selection highlight rect is built via m_inlineTextBox.root().selectionTop() in InlineTextBoxPainter::paintSelection(), so fiddling logic in there is likely. Done naively this means we'd see the text but in cases like this we'd have overlapping selection highlight producing darker region. That's preferable to current invisible text behavior IMO, and is a variant of a similar change we already made in http://crrev.com/1727113007

Longer term we've discussed revising text selection to be done as a unified region that encompasses all selected lines and can thus ensure no overlapping painting. That work has not been scoped but has rough support from in person discussion.

Related historical bug:
 http://crbug.com/385540 

And logic from long ago:
https://chromium.googlesource.com/chromium/src/+/254f59518462db903de6d5955a728435066d651a

Test case can be made much simpler, attached is revision. Not flexbox related at all.

Deleted: selection-no-clip-text.html 263 bytes

selection-no-clip-text.html 263 bytes View Download

From in person discussion:

- it turns out there is *also* an invalidation bug, which I had missed, per video in c#1. I hadn't seen that if you select, and unselect slowly, the accent marks on the text disappear. This is also fixed by the patch in work https://codereview.chromium.org/2546473003/ but ideally we'd add an invalidation test to somehow make sure that aspect doesn't regress.

- my compatriots support changing to fix the painting, at the cost of introducing darker overlap. We compared to FF and Safari selection behavior.

- fast/text/selection-with-inline-padding.html is one test case that produces notably different, but still acceptable, behavior with patch.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e1ac96c0207dd18057fc1f385362b1bee52bb26f

commit e1ac96c0207dd18057fc1f385362b1bee52bb26f
Author: wkorman <wkorman@chromium.org>
Date: Mon Dec 05 23:25:03 2016

Simplify computation of text selection top/bottom.

Leads to a functionality change wherein we will now see
selection highlight overlap in some cases where previously
we avoided it. We've already gone down this path in other
cases, see for example http://crrev.com/1727113007.

This change fixes two issues:

1. A paint invalidation bug that could lead to missing
   glyph bits.

2. A paint issue where text selection rect could be shrunk
   to avoid overlap with preceding line resulting in
   partially invisible glyph portions painted outside of
   the selection rect.

It also removes logic around fiddling selection location,
when floats are present, depending on line offset of
previous/next lines. This could be a relic from selection
gap days. Without problematic specific test cases to
consider, we may as well remove said logic.

BUG= 657325 

Review-Url: https://codereview.chromium.org/2546473003
Cr-Commit-Position: refs/heads/master@{#436446}

[delete] https://crrev.com/d585c64d2fa26f6fad56d903c322bb6f90a324cb/third_party/WebKit/LayoutTests/fast/text/selection-with-inline-padding-expected.html
[modify] https://crrev.com/e1ac96c0207dd18057fc1f385362b1bee52bb26f/third_party/WebKit/LayoutTests/fast/text/selection-with-inline-padding.html
[add] https://crrev.com/e1ac96c0207dd18057fc1f385362b1bee52bb26f/third_party/WebKit/LayoutTests/paint/text/selection-no-clip-text.html
[add] https://crrev.com/e1ac96c0207dd18057fc1f385362b1bee52bb26f/third_party/WebKit/LayoutTests/platform/linux/fast/text/selection-with-inline-padding-expected.png
[add] https://crrev.com/e1ac96c0207dd18057fc1f385362b1bee52bb26f/third_party/WebKit/LayoutTests/platform/linux/fast/text/selection-with-inline-padding-expected.txt
[add] https://crrev.com/e1ac96c0207dd18057fc1f385362b1bee52bb26f/third_party/WebKit/LayoutTests/platform/linux/paint/text/selection-no-clip-text-expected.png
[add] https://crrev.com/e1ac96c0207dd18057fc1f385362b1bee52bb26f/third_party/WebKit/LayoutTests/platform/linux/paint/text/selection-no-clip-text-expected.txt
[add] https://crrev.com/e1ac96c0207dd18057fc1f385362b1bee52bb26f/third_party/WebKit/LayoutTests/platform/mac-mac10.10/fast/text/selection-with-inline-padding-expected.png
[add] https://crrev.com/e1ac96c0207dd18057fc1f385362b1bee52bb26f/third_party/WebKit/LayoutTests/platform/mac-mac10.9/fast/text/selection-with-inline-padding-expected.png
[add] https://crrev.com/e1ac96c0207dd18057fc1f385362b1bee52bb26f/third_party/WebKit/LayoutTests/platform/mac/fast/text/selection-with-inline-padding-expected.png
[add] https://crrev.com/e1ac96c0207dd18057fc1f385362b1bee52bb26f/third_party/WebKit/LayoutTests/platform/mac/fast/text/selection-with-inline-padding-expected.txt
[add] https://crrev.com/e1ac96c0207dd18057fc1f385362b1bee52bb26f/third_party/WebKit/LayoutTests/platform/mac/paint/text/selection-no-clip-text-expected.png
[add] https://crrev.com/e1ac96c0207dd18057fc1f385362b1bee52bb26f/third_party/WebKit/LayoutTests/platform/mac/paint/text/selection-no-clip-text-expected.txt
[add] https://crrev.com/e1ac96c0207dd18057fc1f385362b1bee52bb26f/third_party/WebKit/LayoutTests/platform/win/fast/text/selection-with-inline-padding-expected.png
[add] https://crrev.com/e1ac96c0207dd18057fc1f385362b1bee52bb26f/third_party/WebKit/LayoutTests/platform/win/fast/text/selection-with-inline-padding-expected.txt
[add] https://crrev.com/e1ac96c0207dd18057fc1f385362b1bee52bb26f/third_party/WebKit/LayoutTests/platform/win/paint/text/selection-no-clip-text-expected.png
[add] https://crrev.com/e1ac96c0207dd18057fc1f385362b1bee52bb26f/third_party/WebKit/LayoutTests/platform/win/paint/text/selection-no-clip-text-expected.txt
[add] https://crrev.com/e1ac96c0207dd18057fc1f385362b1bee52bb26f/third_party/WebKit/LayoutTests/platform/win7/fast/text/selection-with-inline-padding-expected.png
[modify] https://crrev.com/e1ac96c0207dd18057fc1f385362b1bee52bb26f/third_party/WebKit/Source/core/layout/line/RootInlineBox.cpp

Tried https://www.slamb.eu/ on Mac Canary 57.0.2943.0 and it looks fixed to me. Highlighting the title and line below does show the overlapping selection highlight as we knew it would (photo attached).

But the invalidation and selection issues captured by this bug should be fixed.

Deleted: Screen Shot 2016-12-06 at 3.09.09 PM.png 9.3 KB

	Screen Shot 2016-12-06 at 3.09.09 PM.png 9.3 KB View Download

Tested same Canary version on Win7 and behavior same as c#17.