Bugzilla

Summarizing our discussion of this bug in this week's team meeting:

How the problem arises:
 * The current mechanism for a page to control whether a touchpad pinch gesture is handled by the browser or by the page is that the browser sends the page a `wheel` event with the Control modifier set (as if you scrolled up/down with the Control key down). The page can `preventDefault()` this event to prevent the browser from handling the gesture.
 * There is a 600ms timeout on waiting for the page to potentially call `preventDefault()`. If the timeout is reached, the browser will handle the gesture without waiting longer.

It would be interesting to find out whether the same problem can arise in other browsers, and if not, what are they doing differently.

Possible solution approaches:
 * Increase or remove the timeout for wheel events with the Control modifier set. The purpose of the timeout is that the same mechanism for wheel events _without_ the Control modifier set allows the page to consume **scroll** gestures, and we didn't want slow pages to interfere with the responsiveness of scrolling too much. Zoom gestures are less common and their responsiveness is less critical than scrolling, so the timeout could be relaxed for zoom gestures, though it wouldn't be ideal.
 * Give the page a declarative way of consuming touchpad zoom gestures, similar to how `touch-action: none` provides a declarative way of consuming scroll and zoom gestures on a touchscreen.
    * There is a [spec discussion](https://github.com/w3c/pointerevents/issues/478) about potentially making `touch-action` **itself** pertain to touchpad gestures.
    * Alternatively, a different property specific to touchpad gestures could be introduced.
      * We'd probably want to collect telemetry to motivate this, e.g. to know what fraction of pages try to consume touchpad zoom gestures, and what the distribution of `preventDefault()` response times is.

Summarizing our discussion of this bug in this week's team meeting:

How the problem arises:
 * The current mechanism for a page to control whether a touchpad pinch gesture is handled by the browser or by the page is that the browser sends the page a `wheel` event with the Control modifier set (as if you scrolled up/down with the Control key down). The page can `preventDefault()` this event to prevent the browser from handling the gesture.
 * There is a 600ms timeout on waiting for the page to potentially call `preventDefault()`. If the timeout is reached, the browser will handle the gesture without waiting longer.

It would be interesting to find out whether the same problem can arise in other browsers, and if not, what are they doing differently.

Possible solution approaches:
 * Increase or remove the timeout for wheel events with the Control modifier set. The purpose of the timeout is that the same mechanism for wheel events _without_ the Control modifier set allows the page to consume **scroll** gestures, and we didn't want slow pages to interfere with the responsiveness of scrolling too much. Zoom gestures are less common and their responsiveness is less critical than scrolling, so the timeout could be relaxed for zoom gestures, though it wouldn't be ideal.
 * Give the page a declarative way of consuming touchpad zoom gestures, similar to how `touch-action: none` provides a declarative way of consuming scroll and zoom gestures on a touchscreen.
    * There is a [spec discussion](https://github.com/w3c/pointerevents/issues/478) about potentially making `touch-action` **itself** pertain to touchpad gestures.
    * Alternatively, a different property specific to touchpad gestures could be introduced.
      * We'd probably want to collect telemetry to motivate this, e.g. to know what fraction of pages try to consume touchpad zoom gestures, and what the distribution of `preventDefault()` response times is.
    * Note, for this approach a resolution would require both the browser implementing support for the relevant declarative property **and** the affected sites adopting the use of this property.