New issue
Advanced search Search tips

Issue 761855 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

float:left breaks selection on newyorker

Project Member Reported by pdr@chromium.org, Sep 4 2017

Issue description

Chrome Version: 62.0.3198.0/dev
OS: MacOS

What steps will reproduce the problem?
(1) Visit https://www.newyorker.com/magazine/2017/09/04/ken-burns-american-canon
(2) Try to select the text "General Merrill McPeak flew two"

The text should select but it does not.

I've attached a minimized testcase.

This regression bisects down to:
Find first paintable LayoutObject w/o canonicalization.
https://chromium.googlesource.com/chromium/src/+/ac04325a74a0a668600ded74c3cfea689f17634c
 
ny.html
170 bytes View Download

Comment 1 by yosin@chromium.org, Sep 5 2017

Labels: -Type-Bug-Regression Type-Bug
Owner: jfernan...@igalia.com
Summary: float:left breaks selection on newyorker (was: first-letter breaks selection on newyorker)
Attached test case containing ::first-letter works fine on M63.
This is fixed by [1] on August 28, 2017.

For newyoker.com case, it is cause by float:left which doesn't work
well on float:left (and float:right)

Assign to jfernandez@ since he is working for hit testing on float[2]


[1] http://crrev.com/c/630341 Make LayoutSelection to handle "::first-letter" correctly
[2] https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/float/blink-dev/qqLz4npBtDY/iXWF-7msAwAJ Improve selection of floats

Comment 2 by pdr@chromium.org, Sep 5 2017

Thanks! That's great that this has been fixed.

Minor nit: I think this is really about first-letter and not float:left. Or, at least first-letter is all that was required in the minimized testcase.
Status: Started (was: Assigned)
I've been looking into this, still not very deeply. First, I think I'd need to land https://crrev.com/c/643106. It doesn't solve the issue but it's a first step in the right direction, addressing the issue for block-level boxes. 

Once that patch land, we will need to address the issues with inline-blocks.

Comment 4 by yosin@chromium.org, Jan 10 2018

Labels: Pri-3
Status: Available (was: Started)
I don't have much time to work on this now, but I'll keep an eye.

Comment 6 by pdr@chromium.org, Jun 1 2018

Can you describe in concrete steps what the remaining tasks are for this bug? Otherwise, lets close as wontfix.
Well, I'm blocked on this CL https://crrev.com/907888 trying to cover all the situations mentioned by Ian Kilpatrick. 

I'm ran out of ideas now, but my last approach was based on finding the closest float to the RootInlineBox receiving the input event. I've prepared a design document about this:

https://docs.google.com/document/d/1o4tEprUEjIoIfZbSs02OBo_WzOw5IK7ZEa3SGF5lRSw/edit#

Although the change in the mentioned CL doesn't fix this issue, I think it's a needed step in the right direction. This and the issues I'm trying to fix share the same root cause: the float selected as result of the HitTesting logic, which will be the end point of the selection, is placed in a previous position in the DOM tree.

So, the first step would be to solve this issue, and find the right RootInlineBox as end of selection when it starts in a float element.

Next steps would be to make the solution robust and coherent for other cases involving float elements.

Finally, I haven't give up on this goal, but it went down on my current list of priorities. I agree on closing this as WONTFIX as it was suggested, with the idea in mind of reopening if eventually I manage to find the time to resume this work.
Status: Assigned (was: Available)

Sign in to add a comment