Unable to select text on muro.deviantart.com on nightly
Categories
(Core :: DOM: Selection, defect, P3)
Tracking
()
People
(Reporter: ailea, Unassigned)
References
()
Details
Attachments
(1 file)
590.58 KB,
video/mp4
|
Details |
Affected versions:
Nightly 78.0a1(2020-05-24)
Tested on:
Windows 7
Windows 10
Ubuntu 20.04
Steps:
- Launch firefox and access: https://muro.deviantart.com/
- Click on the "ABC" icon.
- 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.
Comment 1•4 years ago
|
||
Interesting - do you know which preference could cause the different behaviors on nightly and release builds?
Updated•4 years ago
|
Comment 2•4 years ago
|
||
Indeed interesting. Flipping dom.select_events.textcontrols.enabled
(default true
only on Nightly) triggers the problem.
Comment 3•4 years ago
|
||
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.
Updated•4 years ago
|
Comment 4•4 years ago
|
||
Masayuki: given c3, I'd like to disable this on Nightly too. Or do you have concerns about it?
Comment 5•4 years ago
|
||
- What do other browsers do and why are they not having this issue?
- Is this about
selectstart
andselectionchange
on HTML form controls? If so, we should file an issue against the HTML Standard.
Comment 6•4 years ago
|
||
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.
Comment 7•4 years ago
•
|
||
(In reply to Anne (:annevk) from comment #5)
- What do other browsers do and why are they not having this issue?
- Is this about
selectstart
andselectionchange
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.
Comment 8•4 years ago
|
||
(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.
Comment 9•4 years ago
|
||
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.
Comment 10•4 years ago
|
||
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.
Comment 11•4 years ago
•
|
||
(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
andtextarea
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.
Comment 12•4 years ago
|
||
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.
Comment 13•4 years ago
|
||
(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.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Description
•