Closed Bug 1013424 Opened 10 years ago Closed 9 years ago

Don't scroll for wheel events with certain modifier keys pressed

Categories

(Core :: Panning and Zooming, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1013432

People

(Reporter: mstange, Unassigned)

References

Details

Main thread wheel event handling has lots of special cases for doing non-scroll actions based on wheel events. For example, a wheel event can result in a change to the zoom factor of the website, or it can cause Firefox to go back/forward in the current tab's history. These special actions can even be controlled by prefs.

When handling wheel events on the APZ thread, we need to make sure that we don't scroll for those special events, and that we pass them on to the main thread appropriately. Maybe we need to construct a whitelist of modifier key masks for which we know off-main-thread that these modifier keys will or will not cause scrolling, and send that whitelist to the APZCTM. Or maybe this should be handled by the widget, before the event even reaches the APZCTM?
Yeah I would prefer handling this in widget before the event reaches APZCTM. In fact based on my investigations on wheel handling for metro, I think it might make more sense to always send wheel events to the main thread, and then after doing all the processing there, use some new API to get APZC to actually manage the scroll animation.
But if every event needs to go through the main thread, how does that improve responsiveness when the main thread is busy?
The scroll may be delayed by main thread business, but once it has started it will still be smooth even if the main thread is busy. I agree it's not ideal, but might be worth considering in the short term.
Well, a scroll gesture consists of lots of small wheel events that are fired at a quick rate. I guess we can group them by similar heuristics as the WheelTransaction does at the moment, and then only check for special actions on the initial event, and if that hasn't done anything special, route the follow-up events directly to the APZC. But that sounds more complicated to me.
So the work dvander has done for scroll events on windows does pretty much this. Gonna dupe this bug.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.