Bug 1751510 Comment 18 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

We ran into a complication while working on a test for this in bug 1780121.

The native events produced by the widget and processed by APZ need to be mapped onto web platform events which are dispatched to the web content, and the web content needs to have an opportunity to override the browser's default handling of the events by calling `preventDefault()`.

As there are no events directly representing touchpad touches or pinch gestures in the web platform, for touchpad pinch gestures we map them onto `wheel` events with the `Ctrl` modifier set, with their `deltaY` set based on the amount of zooming (i.e. based on the change in finger span relative to the last event).

We have some code to drop pinch gesture events where the span change is zero, because in such cases the events would not get dispatched to content and, on pages which want to handle the zooming themselves, content would not get a chance to `preventDefault()` those events. This has led to bugs such as bug 1700819.

But dropping events with a zero span change means that two-finger panning won't work. (During manual testing, I'm guessing it worked because at least some events actually had a small amount of span change; however, events that did have a zero span change got dropped and this probably contibuted to the two-finger pan feeling slow. In our test, we tried to synthesize events which consistently had zero span change and those did not result in panning at all.)

Timothy, do you know if we support two-finger panning as a part of a pinch gesture on Windows touchpads? If so, how do we handle this, i.e. what sort of events do we send to APZ and to content during the pan phase of the gesture?
We ran into a complication while working on a test for this in bug 1780121.

The native events produced by the widget and processed by APZ need to be mapped onto web platform events which are dispatched to the web content, and the web content needs to have an opportunity to override the browser's default handling of the events by calling `preventDefault()`.

As there are no events directly representing touchpad touches or pinch gestures in the web platform, for touchpad pinch gestures we map them onto `wheel` events with the `Ctrl` modifier set, with their `deltaY` set based on the amount of zooming (i.e. based on the change in finger span relative to the last event).

We have some code to drop pinch gesture events where the span change is zero, because in such cases the `wheel` events would have `deltaY=0` and not get dispatched to content and, on pages which want to handle the zooming themselves, content would not get a chance to `preventDefault()` those events. This has led to bugs such as bug 1700819.

But dropping events with a zero span change means that two-finger panning won't work. (During manual testing, I'm guessing it worked because at least some events actually had a small amount of span change; however, events that did have a zero span change got dropped and this probably contibuted to the two-finger pan feeling slow. In our test, we tried to synthesize events which consistently had zero span change and those did not result in panning at all.)

Timothy, do you know if we support two-finger panning as a part of a pinch gesture on Windows touchpads? If so, how do we handle this, i.e. what sort of events do we send to APZ and to content during the pan phase of the gesture?
We ran into a complication while working on a test for this in bug 1780121.

The native events produced by the widget and processed by APZ need to be mapped onto web platform events which are dispatched to the web content, and the web content needs to have an opportunity to override the browser's default handling of the events by calling `preventDefault()`.

As there are no events directly representing touchpad touches or pinch gestures in the web platform, for touchpad pinch gestures we map them onto `wheel` events with the `Ctrl` modifier set, with their `deltaY` set based on the amount of zooming (i.e. based on the change in finger span relative to the last event).

We have some code to drop pinch gesture events where the span change is zero, because in such cases the `wheel` events would have `deltaY=0` and not get dispatched to content and, on pages which want to handle the zooming themselves, content would not get a chance to `preventDefault()` those events. This has led to bugs such as bug 1700819.

But dropping events with a zero span change means that pan-only movement during the pinch gesture won't work. (During manual testing, I'm guessing it worked because at least some events actually had a small amount of span change; however, events that did have a zero span change got dropped and this probably contibuted to the two-finger pan feeling slow. In our test, we tried to synthesize events which consistently had zero span change and those did not result in panning at all.)

Timothy, do you know if we support two-finger panning as a part of a pinch gesture on Windows touchpads? If so, how do we handle this, i.e. what sort of events do we send to APZ and to content during the pan phase of the gesture?

Back to Bug 1751510 Comment 18