The number of ranges differ between Firefox and other browsers when the selection contains <button> element
Categories
(Core :: DOM: Selection, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox105 | --- | affected |
People
(Reporter: github, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: parity-chrome, parity-edge)
Attachments
(1 file)
643 bytes,
text/html
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.96 Safari/537.36
Steps to reproduce:
- Select all text on page
- Press Ctrl+C
- Observe new selection and the text in alert window
Actual results:
- getSelection().toString() returns "some text"
- Calling getRangeAt and addRange with the same range sets the wrong selection
Expected results:
- toString() should return the full string that was selected "some text button more text after button"
- Removing and re-adding selection range should keep the same selection as the user did
Chrome and Edge correctly do this behaviour while Firefox completely stops at the button element and doesn't wrap around it.
Comment 1•5 years ago
|
||
Firefox returns 2 ranges for the case, but the testcase doesn't handle the 2nd range,
that results in removing the latter part from the selection.
You can check the number of ranges by selection.rangeCount.
leaving open, given I don't know if it's spec-ed how many ranges should be created for this case.
Either way, "window.getSelection().toString()" returns truncated text, which sounds a like bug to me in its own right.
Even if you check all the ranges, the button will be missing from all of them, as it appears that buttons can't be selected at all in Firefox, while in other buttons the text inside of the buttons does get selected.
Adding "button { -moz-user-select: text; }" style fixes this problem entirely (button is selectable, returns only one range, toString() returns full text).
For comparison, adding "button { user-select: none; }" in Chrome still returns one range, and it still contains the button element within that range.
- Firefox makes <button> unselectable by default
- Firefox creates multiple ranges which go around the unselectable button element
- Chrome with user-select:none still returns only one range with button in it
After some digging, all of the issues seem to boil down to this specification: https://drafts.csswg.org/css-ui-4/#valdef-user-select-none
Updated•5 years ago
|
Comment 5•2 years ago
|
||
For what it's worth, I just checked the attached test case in Nightly 105.0a1 (2022-08-12) and can confirm that the issue persists.
Sebastian
Comment 6•2 years ago
|
||
The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.
Updated•2 years ago
|
Description
•