Closed Bug 1098430 Opened 10 years ago Closed 9 years ago

Do proper APZC target-confirmation for pangesture events

Categories

(Core :: Panning and Zooming, defect)

All
macOS
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: kats, Unassigned)

References

(Blocks 1 open bug)

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.
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: apz-desktop
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
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.