Open Bug 1526896 Opened 5 years ago Updated 2 years ago

The number of ranges differ between Firefox and other browsers when the selection contains <button> element

Categories

(Core :: DOM: Selection, defect, P3)

66 Branch
defect

Tracking

()

Tracking Status
firefox105 --- affected

People

(Reporter: github, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: parity-chrome, parity-edge)

Attachments

(1 file)

Attached file firefox-copy.html

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:

  1. Select all text on page
  2. Press Ctrl+C
  3. Observe new selection and the text in alert window

Actual results:

  1. getSelection().toString() returns "some text"
  2. Calling getRangeAt and addRange with the same range sets the wrong selection

Expected results:

  1. toString() should return the full string that was selected "some text button more text after button"
  2. 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.

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.

Component: Untriaged → Selection
Product: Firefox → Core
Summary: window.getSelection() stops at <button> elements → The number of ranges differ between Firefox and other browsers when the selection contains <button> element
Whiteboard: [parity-chrome][parity-edge]

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.

  1. Firefox makes <button> unselectable by default
  2. Firefox creates multiple ranges which go around the unselectable button element
  3. 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

Priority: -- → P3

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

Whiteboard: [parity-chrome][parity-edge]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: