Closed Bug 1970030 Opened 24 days ago Closed 10 days ago

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)

Firefox 141
Desktop
All
defect

Tracking

()

RESOLVED FIXED
141 Branch
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

Summary: dom.input.number_and_range_modified_by_mousewheel => true is now scrolling the page as well at the same time as incrementing the number field → dom.input.number_and_range_modified_by_mousewheel => true is now scrolling the page as well as incrementing the number field

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.

Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core
Status: UNCONFIRMED → NEW
Component: DOM: Core & HTML → DOM: UI Events & Focus Handling
Ever confirmed: true
OS: Unspecified → All
Regressed by: 1356293
Hardware: Unspecified → Desktop

: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.

Flags: needinfo?(vhilla)
Flags: needinfo?(vhilla)
See Also: → 1261673

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 in GetEventTargetParent or such.

:edgar, do you think the second option is fine?

Severity: -- → S3
Flags: needinfo?(echen)

(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 in GetEventTargetParent or such.

:edgar, do you think the second option is fine?

Yes, having a new flag to handle this sounds fine. Thank you!

Flags: needinfo?(echen)

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?

Flags: needinfo?(vhilla)

dom.input.number_and_range_modified_by_mousewheel pref is off by default, so setting firefox140 to disabled.

Assignee: nobody → vhilla
Attachment #9493762 - Attachment description: WIP: Bug 1970030 - Let input element make wheel event uncancelable. r=edgar → Bug 1970030 - Let input element keep a wheel event cancelable. r=edgar
Status: NEW → ASSIGNED

I'm working on a fix and it should not be risky, but might not be in time.

Flags: needinfo?(vhilla)

(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 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?

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.

Status: ASSIGNED → RESOLVED
Closed: 10 days ago
Resolution: --- → FIXED
Target Milestone: --- → 141 Branch

Set release status flags based on info from the regressing bug 1356293

QA Whiteboard: [qa-triage-done-c142/b141][qa-ver-opt-c142/b141]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: