New issue
Advanced search Search tips
Starred by 2 users

Issue metadata

Status: Started
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, Aug 24 2017

Issue description

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. 

273 bytes View Download
This issue could be the same, or quite similar, to the one reported in

Comment 2 by, Aug 25 2017

Owner: ----
Status: Available (was: Untriaged)
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 ?
Status: Started (was: Available)

Comment 5 by, Aug 29 2017

Blockedon: 590296
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:

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 ( 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.

Comment 8 by, Aug 29 2017

I think a 1 was dropped; the correct url for WebKit is
Filed a similar bug in FF
Yes, sorry about the WK bug mistake. We can consider as the meta-bug for all this selection issues with floats. 

I've filed as a first step. That is what my patch in addresses now.
FTR, I filed for Firefox to track this issue there. 
Blockedon: 549211
Project Member

Comment 13 by, Dec 12 2017

The following revision refers to this bug:

commit ebf3a5282adcb4eaa862516508517d57ae052009
Author: Javier Fernandez <>
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

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-by: Philip Rogers (OOO) <>
Commit-Queue: Javier Fernandez <>
Cr-Commit-Position: refs/heads/master@{#523410}

Sign in to add a comment