Do proper APZC target-confirmation for pangesture events

RESOLVED WORKSFORME

Status

()

Core
Panning and Zooming
RESOLVED WORKSFORME
4 years ago
2 years ago

People

(Reporter: kats, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
All
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Bug 1090398 introduces the concept of "target confirmation" when the APZ code is dealing with input events. This allows the events to be dealt by the correct APZC instance in the face of insufficient hit-test data on the compositor thread. It does so by waiting for gecko to do a hit-test on the main thread.

The patches on bug 1090398 implement this behaviour for touch input events, but not other kinds of events like the pan gesture events we get on OS X. This bug is about making this work for pan gesture events as well. This will likely involve constructing input blocks from the pan gesture events and doing the same sort of triple-notification-wait that we do for touch input events. Scroll wheel events will likely also need to do something similar.
See Also: → bug 1013432
Blocks: 1013364
With the current OS X widget code, the "pangesture" events only get used if the layers.async-pan-zoom.separate-event-thread pref is true, which is not the case by default. Leaving this bug open for now since we don't know if/when we'll get around to enabling that pref (other events will need to move off onto the new event thread as well so it's non-trivial).
Blocks: 1166360
No longer blocks: 1013364
Depends on: 1193062
We do this already by turning the pangesture inputs into wheel events in the widget code in OS X and treating them the same as we do other wheel events.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.