1705584 - prevent defaulted in dommousescroll handler doesn't prevent scrolling on macOS

Status: NEW

(Core :: Panning and Zooming, defect, P3)

Description

[Timothy Nikkel (:tnikkel)]

Attachment: wevdms.html

See testcase. The most likely cause is that we dispatch a scroll event that has zero delta so it doesn't get sent to content like bug 1661108 on Windows with dmanip.

Comment 1

[Dan Robertson (:dlrobertson)]

I wonder if this related to bug 1261741? Still doing some initial debugging... My first attempt at ignoring zero delta's does make the issue less likely to occur, but given enough attempts I can still reproduce this.

Comment 2

[Dan Robertson (:dlrobertson)]

Attachment: Bug 1705584 - Test that a small wheel scroll can be prevented. r?botond,tnikkel

Comment 3

[Dan Robertson (:dlrobertson)]

Note that in the push to try for the test patch here, all OSes fail the test for DOMMouseScroll, but pass with a wheel event. I think we may be hitting what was discussed in here, but I have a bit more digging to do to verify this.

Comment 4

[Dan Robertson (:dlrobertson)]

As stated by Botond in

The MDN page for DOMMouseScroll says the following:

If you want to prevent the default action of mouse wheel events, it's not enough to handle only this event on Gecko because If scroll amount by a native mouse wheel event is less than 1 line (or less than 1 page when the system setting is by page scroll), other mouse wheel events may be fired without this event.

So I think what we're seeing is the expected behavior. I think based on the MDN page, this is a WONTFIX.

Comment 5

[Dan Robertson (:dlrobertson)]

Note that the MDN page also aligns with what I see with the tests in D167853

Comment 6

[Botond Ballo [:botond]]

Timothy, do you agree that this is a wontfix based on comment 4, or is there a subtlety / other consideration we're missing?

Comment 7

[Timothy Nikkel (:tnikkel)]

Does our behaviour on macos match other browsers on macos? Does it match our behaviour on other os's? Does it match other browsers on other os's? I don't remember the details right now, but the way that I worded this bug suggests that at least one of those answers is no and content does expect this to happen?

Comment 8

[Botond Ballo [:botond]]

DOMMouseScroll is a non-standard Firefox extension which according to its MDN page is not supported by any other browser, so the behaviour of other browsers doesn't seem applicable here.

Comment 9

[Dan Robertson (:dlrobertson)]

(In reply to Timothy Nikkel (:tnikkel) from comment #7)

Does our behaviour on macos match other browsers on macos? Does it match our behaviour on other os's? Does it match other browsers on other os's? I don't remember the details right now, but the way that I worded this bug suggests that at least one of those answers is no and content does expect this to happen?

See comment #3: Note that in the push to try for the test patch here, all OSes fail the test for DOMMouseScroll, but pass with a wheel event.

So no other browser officially supports DOMMouseScroll and our behavior on all OSes is the same.

Comment 10

[Timothy Nikkel (:tnikkel)]

The behaviour I see locally when I use the attached html testcase:

one) using the touchpad to scroll over the yellow div: scrolls very laggy/slowly/intermittently
two) using a mousewheel over the yellow div: no scrolling.

one) seems like a bug, it should either scroll or not scroll
and it seems like whatever the resolution, two) should probably match one)?

Comment 11

[Dan Robertson (:dlrobertson)]

(In reply to Timothy Nikkel (:tnikkel) from comment #10)

The behaviour I see locally when I use the attached html testcase:

one) using the touchpad to scroll over the yellow div: scrolls very laggy/slowly/intermittently
two) using a mousewheel over the yellow div: no scrolling.

one) seems like a bug, it should either scroll or not scroll
and it seems like whatever the resolution, two) should probably match one)?

I think it is highly unlikely we could get one to match two. Precision pixel scrolls from a touchpad will not be able to be prevented with DOMMouseScroll, and it makes sense that a mousewheel is prevented since it should produce a scroll with a scroll unit of some number of lines.

Comment 12

[Botond Ballo [:botond]]

To elaborate a bit: the crux of the issue here is that the DOMMouseScroll event's delta is denominated in a whole number of lines. It's basically a legacy event type whose design predates input methods that scroll by more precise amounts than whole lines, such as touchpads. As such, it's expected that its behaviour is broken with touchpads.

The reason scrolling using the touchpad over the yellow div behaves as it does is that the touchpad generates a stream of events where most events have a smaller delta than one line, and thus do not generate a DOMMouseScroll event (which is the only event type the page preventDefault()s), while some events have a large enough delta to generate a DOMMouseScroll event.

So, I don't know what course of action we could take that achieves the goals described in comment 10 without having worse webcompat impact. A couple of things we could conceivably do:

• Do not respect preventDefault() for DOMMouseScroll events at all. This would break pages that want to prevent browser scrolling, and on Firefox do so only by listening to DOMMouseScroll. Such pages are already broken with touchpads, but this change would break them with mouse wheel too.
• Try to respect preventDefault() consistently, by only firing DOMMouseScroll once we have accumulated a large enough pixel delta that it constitutes a whole line. This would mean having to hold back the actual scrolling itself while we're accumulating that delta (in case the eventual DOMMouseScroll is prevented and so the scrolling shouldn't happen). In addition to implementation complexity, this likely also has unacceptable webcompat impact (e.g. now a small touchpad scroll that's too small to be a line doesn't cause scrolling at all; merely registering a non-passive DOMMouseScroll listener has the effect of changing the page's scrolling behaviour).
• Fire DOMMouseScroll events with fractional deltas. I don't think we can do this because the delta is communicated in the detail field which has type long, and this is specified in the UIEvent base class which is a standard interface.

If there are other solution approaches I haven't thought of that have an acceptable webcompat impact, I'm open to considering them.

Comment 13

[Botond Ballo [:botond]]

Discussed this in our planning meeting today. As we don't see a realistic way forward here, we removed this from our Stabilization Sprint 2a and kicked it back to our backlog.

I'm open to considering suggestions for how to move forward with this (and we can re-prioritize as needed).