window.getSelection() inaccurate after triple-click
Categories
(Core :: DOM: Selection, defect)
Tracking
()
People
(Reporter: cariad, Unassigned)
References
()
Details
(Keywords: parity-chrome)
Attachments
(1 file)
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:96.0) Gecko/20100101 Firefox/96.0
Steps to reproduce:
Triple-clicking a div with contenteditable="true" will appear to select all the text, but window.getSelection() reports the selection length as only 1.
To reproduce:
- Open https://codepen.io/cariad/pen/mdBZjMO.
- Select some of the "Lorum ipsum" text then press 'c' to see the anchorOffset and focusOffset reported by window.getSelection(). Confirm that you agree with the results.
- Triple-click the "Lorum ipsum" text to select the entire paragraph, then press 'c'. window.getSelection() reports that the selection starts at index 0 and ends at index 1.
Actual results:
window.getSelection() reports that the selection ends at index 1, and not at the end of the selection indicated by the UI.
Expected results:
After triple-clicking a block of text, I expect the window.getSelection() to report that the selection has the same length as the selection indicated in the UI.
I've tried this only in Firefox 96.0 in Ubuntu and no other operating systems. In comparison, Chrome 97.0.4692.71 does not exhibit this behaviour.
Comment 1•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Editor' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 2•2 years ago
|
||
Reproducible on Nightly 98, Win11.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 3•2 years ago
|
||
A triple click selects all nodes in the <div contenteditable>
rather than starting from and ending by leaf node(s) (if there is no <br>
elements).
It might be possible to appear some broken web apps which depend on Chrome's behavior though. I don't think we should change this behavior right now because it's hard to keep compatibility for edge cases of digging into the DOM nodes to find leaf nodes. Therefore, I believe that using similar behavior as Selection.selectAllChildren
internally does make sense.
https://searchfox.org/mozilla-central/rev/d5113f9c616b75b7919916f5fe4b4f8f78191ac9/layout/generic/nsIFrame.cpp#8621
Description
•