select "change" event no longer provides user input/gesture activation
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
People
(Reporter: karlt, Assigned: emilio)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: parity-chrome, regression)
Attachments
(2 files)
STR:
- Open testcase.
- Click on "Option 1".
- Wait at least 6 seconds.
- Click on "Option 2".
Actual: no new tab.
Expected: new tab, as in Chrome.
Reporter | ||
Comment 1•2 years ago
|
||
Popup control state is set to openControlled
for the "change" event and UserActivation::IsHandlingUserInput()
returns true, but ConsumeTransientUserGestureActivation()
returns false (even though it is documented to always return true).
This is a regression from https://hg.mozilla.org/mozilla-central/rev/68af110cd33e39111ef50541073b3c681a59bc2b#l3.12
Reporter | ||
Comment 2•2 years ago
|
||
Activation triggering input was previously specified to include "change" events, but "high-level" events were dropped as unnecessary because high-level events are always triggered from low-level user input events such as mousedown/keydown. That is probably true but the triggering low-level events do not necessarily cause "firing of an activation triggering input event in B's active document". With selects, Firefox dispatches to the document mousedown, but not keydown when the events were received on an open select dropdown. Chrome dispatches neither.
Even in Firefox, isTrusted is false because the synthetic event was constructed with the content window.
In 2018, the "change" event triggered activation in all browsers.
Reporter | ||
Comment 3•2 years ago
|
||
selectAudioOutput()
also wants transient activation during "change".
e.g. https://jan-ivar.github.io/dummy/gum_picker_output2.html
Updated•2 years ago
|
Comment 4•2 years ago
|
||
Set release status flags based on info from the regressing bug 1679456
:emilio, since you are the author of the regressor, bug 1679456, could you take a look? Also, could you set the severity field?
For more information, please visit auto_nag documentation.
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 5•2 years ago
|
||
Comment 8•2 years ago
|
||
bugherder |
Comment 9•2 years ago
|
||
The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox105
towontfix
.
For more information, please visit auto_nag documentation.
Assignee | ||
Comment 10•2 years ago
|
||
probably not, it's a fairly old regression.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 11•2 years ago
|
||
I've reproduced this issue on an affected nightly build from 2022-09-06, on Win 10.
Verified as fixed on Firefox 106.0 (20221010110315) on Win 10, Ubuntu 21.04 and mac0S 10.15.
Description
•