New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 2 users
Status: Started
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocked on:
issue 549211
issue 590296



Sign in to add a comment
Selection jumps when crossing float's boundaries
Project Member Reported by jfernan...@igalia.com, Aug 24 Back to list
Chrome Version: 60.0.3112.78 (Official Build) (64-bit)
OS: linux

What steps will reproduce the problem?
(1) Load the attached test case
(2) Start selecting inside the float box
(3) Extend selection outside the float box

What is the expected result?

Highlighted text should match start/end visual selection point.

What happens instead?

The selection start/end points are inverted, so the highlighted text is
the one from the beginning of the float box to the selection start point. 

 
dragSelectionExtent1.html
273 bytes View Download
This issue could be the same, or quite similar, to the one reported in https://webkit.org/b/10177
Owner: ----
Status: Available
I'm working on a patch that may solve, or at least improve, the behavior of selection with floats. It seems that we deliberately ignore float elements when evaluating HitTest candidates. 

We indeed do it explicitly in LayoutBlock::IsChildHitTestCandidate when processing the position of a selection point for block elements and implicitly when dealing with inline elements in LayoutBlockFlow::PositionForPoint function.

My current approach is to stop ignoring float elements and try to figure out the closest candidate to the selection point. Is this a valid approach or are there good reasons to continue ignoring floats ?
Owner: jfernan...@igalia.com
Status: Started
Blockedon: 590296
Cc: pdr@chromium.org
Components: Blink>HitTesting
I recently worked on (and reviewed) some hit testing code and found it a difficult area because it's poorly spec'd (e.g., hit testing is sort-of paint order, selection is sort-of dom-order, and paint order can be completely independent of dom order: https://goo.gl/2wfE7x).

My intuition is to err on the side of cross-browser compatibility. Safari/WebKit, Firefox/Gecko, and Blink all have the jumping behavior in your example, and only Edge has behavior you're suggesting. Would be possible to get together with folks from WebKit and Gecko (and Edge too) to see if this could be made in all engines at once?
Regarding floats: did you look at the code revision history to see why floats
were excluded in the first place? Hopefully there are attached use cases that
could be studied as part of this bug.
My idea is to work in parallel on WebKit (https://webkit.org/b/10177 so hopefully we'll reach and agreement about the expected behavior. We should only land patches which don't break browser interoperability. 

I'll file a bug on Firefox to gather additional opinions.
I think a 1 was dropped; the correct url for WebKit is https://webkit.org/b/101771.
Yes, sorry about the WK bug mistake. We can consider  https://webkit.org/b/101771 as the meta-bug for all this selection issues with floats. 

I've filed https://bugs.webkit.org/show_bug.cgi?id=176096 as a first step. That is what my patch in https://crrev.com/c/643106 addresses now.
FTR, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1397514 for Firefox to track this issue there. 
Blockedon: 549211
Project Member Comment 13 by bugdroid1@chromium.org, Dec 12
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ebf3a5282adcb4eaa862516508517d57ae052009

commit ebf3a5282adcb4eaa862516508517d57ae052009
Author: Javier Fernandez <jfernandez@igalia.com>
Date: Tue Dec 12 12:06:05 2017

Consider floats as HitTest candidate for selection

Selection with floats has a weird and unpredictable behavior. The root
cause is that floats are not considered valid HitTest candidates.

There are many other cases where float elements are ignored when
traversing the tree looking for the closes element to a specific
LayoutPoint.

This patch address just one of this cases, where floats are children
of a in-flow block-level box.

Bug: 758526
Change-Id: I918af3ee21aa1070fa03a9fe1073205cc0a57300
Reviewed-on: https://chromium-review.googlesource.com/643106
Reviewed-by: Philip Rogers (OOO) <pdr@chromium.org>
Commit-Queue: Javier Fernandez <jfernandez@igalia.com>
Cr-Commit-Position: refs/heads/master@{#523410}
[add] https://crrev.com/ebf3a5282adcb4eaa862516508517d57ae052009/third_party/WebKit/LayoutTests/editing/selection/select-out-of-floated-non-editable.html
[modify] https://crrev.com/ebf3a5282adcb4eaa862516508517d57ae052009/third_party/WebKit/Source/core/layout/LayoutBlock.cpp

Sign in to add a comment