dom.input.number_and_range_modified_by_mousewheel => true is now scrolling the page as well as incrementing the number field
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr128 | --- | unaffected |
firefox-esr140 | --- | affected |
firefox139 | --- | unaffected |
firefox140 | --- | disabled |
firefox141 | --- | fixed |
People
(Reporter: iain.waugh, Assigned: vhilla)
References
(Regression)
Details
(Keywords: nightly-community, regression)
Attachments
(1 file)
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:141.0) Gecko/20100101 Firefox/141.0
Steps to reproduce:
I have the setting about:config => dom.input.number_and_range_modified_by_mousewheel => true to enable me to increase the value of number input type="number" fields with the mousewheel
Actual results:
Whilst the number input was increased, it also scrolled the page at the same time!
Expected results:
Only the number should have been increased, and the webpage not scrolled
Comment 1•24 days ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
![]() |
||
Comment 2•24 days ago
|
||
I can reproduce the issue on Windows11:
Regression window:
https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=be1d4a9a5e7701ac3057fc5145e0859c87ab84f3&tochange=4d7633e12307617a5f9f1eb38918f7a3043c6738
Suspect: Bug 1356293
Comment 3•24 days ago
|
||
:vhilla, since you are the author of the regressor, bug 1356293, could you take a look? Also, could you set the severity field?
For more information, please visit BugBot documentation.
Assignee | ||
Comment 4•24 days ago
|
||
This functionality is implemented here in HTMLInputElement::PostHandleEvent
and will prevent default the wheel event. But there is no non-passive listener, so per bug 1356293 and the spec, we'll mark the event as cancelable=false
. This means prevent default is a noop.
I think we should
- have input elements attach a non-passive listener if this pref is set, or
- make
maybeUncancelable
a flag on the event so that input element can clear it inGetEventTargetParent
or such.
:edgar, do you think the second option is fine?
Comment 5•24 days ago
|
||
(In reply to Vincent Hilla [:vhilla] from comment #4)
I think we should
- have input elements attach a non-passive listener if this pref is set, or
- make
maybeUncancelable
a flag on the event so that input element can clear it inGetEventTargetParent
or such.:edgar, do you think the second option is fine?
Yes, having a new flag to handle this sounds fine. Thank you!
Comment 6•21 days ago
|
||
Next week is the final week of beta for Fx140
:vhilla, any concerns with having a fix in time that is safe for an uplift?
The steps in Comment 0 mention dom.input.number_and_range_modified_by_mousewheel
, which was disabled in Bug 1741469. Any reason we need to fix this in time for Fx140?
Assignee | ||
Comment 7•17 days ago
|
||
Comment 8•17 days ago
|
||
dom.input.number_and_range_modified_by_mousewheel
pref is off by default, so setting firefox140 to disabled.
Updated•16 days ago
|
Assignee | ||
Comment 9•16 days ago
|
||
I'm working on a fix and it should not be risky, but might not be in time.
Comment 10•15 days ago
|
||
(In reply to Donal Meehan [:dmeehan] from comment #6)
Next week is the final week of beta for Fx140
:vhilla, any concerns with having a fix in time that is safe for an uplift?
The steps in Comment 0 mentiondom.input.number_and_range_modified_by_mousewheel
, which was disabled in Bug 1741469. Any reason we need to fix this in time for Fx140?
Since the pref is disabled by default and it is quite late, I'm not eager to uplift this to Beta.
One thing we need to consider is that 140 will be next ESR, we might want to uplift this to 140 ESR. But the pref is also disabled by default there, so we could request a uplift to ESR later when it is safe.
Comment 11•10 days ago
|
||
Comment 12•10 days ago
|
||
bugherder |
Comment 13•3 days ago
|
||
Set release status flags based on info from the regressing bug 1356293
Updated•3 days ago
|
Description
•