1241276 - Interesting edge case - both AccessibleCaret Handles visible with collapsed selection

Status: NEW

(Core :: DOM: Selection, defect)

Description

[Mark Capella [:capella]]

I ran into this odd case...

On this specific mobile page [0] ... and at this specific text-selection [1], I can seem to drag both handles together into a collapsed selection.

Exploring a little, it seems that long-pressing the word |Moto| actually creates an nsISelection of: | Moto| ... (text length == 5 with the leading space included), though the handles don't visually indicate that.

Dragging the handles "together" visually shows a collapsed selection, but the actual text selection is of a single space | |, length == 1.


[0] http://www.cnet.com/products/google-nexus-5x/
[1] https://www.dropbox.com/s/xus2wi70v5z8ymj/cnet_SelectionBug.mp4?dl=0

Comment 1

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

This is a really interesting case. From the source code, there are multiple spaces between $400 and Moto. Basically, long-pressing to select a word on mobile behaves the same as double-clicking to select a word on desktop.

On desktop, I can reproduce this issue by:
1. Open "data:text/html,<p>$400     Moto</p>"
2. Double-click on Moto.
3. Observe the selection range in debug console by typing "window.getSelection().getRangeAt(0).toString()".
I got "    Moto" (with all the leading spaces before Moto)

However if there are only one space between $400 and Moto, I got "Moto" (without any leading space)

In both cases, Google Chrome will select Moto without any spaces. So this looks like a bug to me.

Comment 2

[Mark Capella [:capella]]

Right. In the page the <p> source content text is  is; |$400  	Moto|, which seems to be (2) spaces and (1) tab.

The contents of the |rendered then selected| text is only separated by a single space.

This was fun  :) I saw the behavior and knew something was wrong !