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

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.