Open Bug 1241276 Opened 4 years ago Updated 2 years ago
Interesting edge case - both Accessible
Caret Handles visible with collapsed selection
I ran into this odd case... On this specific mobile page  ... and at this specific text-selection , 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.  http://www.cnet.com/products/google-nexus-5x/  https://www.dropbox.com/s/xus2wi70v5z8ymj/cnet_SelectionBug.mp4?dl=0
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.
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 !
You need to log in before you can comment on or make changes to this bug.