Open Bug 1640637 Opened 4 years ago Updated 4 years ago

Unable to select text on muro.deviantart.com on nightly

Categories

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

78 Branch
defect

Tracking

()

Tracking Status
firefox76 --- disabled
firefox77 --- disabled
firefox78 --- affected
firefox79 --- affected
firefox80 --- affected

People

(Reporter: ailea, Unassigned)

References

()

Details

Attachments

(1 file)

Attached video Select text issue.mp4

Affected versions:

Nightly 78.0a1(2020-05-24)

Tested on:

Windows 7
Windows 10
Ubuntu 20.04

Steps:

  1. Launch firefox and access: https://muro.deviantart.com/
  2. Click on the "ABC" icon.
  3. In the right part, try to select the text from the "Annotation Text" area.

Actual result:

The user cannot select text.

Expected result:

Text should be selected.

Regression range:

The issue is reproducible only on Nightly builds. This is not reproducible in Release 76 and Beta 77, but its reproducible on Nightly 76 and Nightly 77 (maybe a pref that is enabled by default just in nightly builds), so I cannot find a regression range using mozregression. Also the issue is not reproducible on Chrome.

Interesting - do you know which preference could cause the different behaviors on nightly and release builds?

Flags: needinfo?(mbrodesser)
Flags: needinfo?(mbrodesser)

Indeed interesting. Flipping dom.select_events.textcontrols.enabled (default true only on Nightly) triggers the problem.

More information about the pref at the time it was added can be found here.

Given the pref is already false in release builds and this isn't specified, we could consider setting it to false for Nightly builds too. Practically, I don't see this being specified soon.

Summary: Unable to select text on muro.deviantart.com → Unable to select text on muro.deviantart.com on nightly

Masayuki: given c3, I'd like to disable this on Nightly too. Or do you have concerns about it?

  1. What do other browsers do and why are they not having this issue?
  2. Is this about selectstart and selectionchange on HTML form controls? If so, we should file an issue against the HTML Standard.

It seems that Chrome dispatches selectionchange events on <input> element even in release channel. So, I also think why does this happen only on Firefox Nightly.

(In reply to Anne (:annevk) from comment #5)

  1. What do other browsers do and why are they not having this issue?
  2. Is this about selectstart and selectionchange on HTML form controls? If so, we should file an issue against the HTML Standard.

It's about <input> and <textarea> elements. There's https://github.com/w3c/selection-api/issues/53 already.

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #6)

It seems that Chrome dispatches selectionchange events on <input> element even in release channel. So, I also think why does this happen only on Firefox Nightly.

About Chrome: yes, that's what it does. However, that violates the spec, because the Selection range's boundary points aren't mutated. The Selection (and its range) only points to the <textarea> (or <input>) node, not to it's selected text.

Interestingly, even with dom.select_events.textcontrols.enabled set to true no selectionchange events are dispatched when moving the cursor inside of a <textarea>.

However, selectstart events are dispatched when a new, non-collapsed selection is made inside of the <textarea>. These events are not dispatched on Chrome, so I conjecture this difference is what breaks the reporter's website.

Therefore, as a quickfix, it seems not dangerous to set dom.select_events.textcontrols.enabled to false on Nightly too. In the long term, the spec should be fixed.

I'm not sure why we need a quickfix for Nightly-only bugs.

I'm also not sure it can be said that Chrome violates the specification as the way these things work for input and textarea are necessarily different as they operate on an internal value of the element and therefore cannot meaningfully mutate the boundary points.

(In reply to Anne (:annevk) from comment #10)

I'm not sure why we need a quickfix for Nightly-only bugs.

True, we don't. In this case, the fix would be very simple though and I don't see the benefit of having it activated in Nightly.

I'm also not sure it can be said that Chrome violates the specification as the way these things work for input and textarea are necessarily different as they operate on an internal value of the element and therefore cannot meaningfully mutate the boundary points.

From a spec-lawyers point of view, it seems it's violated.

It's only violated if you don't account for the open issues. Which is why we need tests to move this forward. And the reason I would leave it enabled is to find more edge cases we need to fix (e.g., through tests added on WPT or other sites) and ensure to some extent we don't regress what we have.

(In reply to Anne (:annevk) from comment #12)

It's only violated if you don't account for the open issues.

True.

Which is why we need tests to move this forward. And the reason I would leave it enabled is to find more edge cases we need to fix (e.g., through tests added on WPT or other sites) and ensure to some extent we don't regress what we have.

Ok, then let's leave it enabled on Nightly for now.

Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: