1866028 - Pinch to zoom: user gets stuck unable to reset viewport zoom on Figma, Miro and other websites that override pinch gestures

Status: UNCONFIRMED

(Core :: Panning and Zooming, defect, P3)

Description

[icinoe]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/119.0

Steps to reproduce:

• Go to to miro.com (or other canvas/board/design web tool, on a heavy file or laggy device)
• Use pinch-to-zoom fast and repeatedly until it lags so that Firefox native pinch to zoom triggers instead of web app's zoom

Actual results:

• stay stuck with no way to reset viewport zoom

Expected results:

• Pinch to zoom should not trigger when an app overrides pinch gesture
• In case zoom on viewport is active after pinching, pinching to zoom out should reset viewport zoom and not be overrided by any website

Alternatively, there should be a feature to reset pinch to zoom so that users do not get stuck

More detail:
Happens repeatedly on web apps that override the pinch gesture to zoom on their canvas, like Figma, Miro, Mural and other design software.
Whenever a small lag happens, pinch-to-zoom triggers the Firefox zoom in the viewport instead of triggering the web app zoom. Once viewport is zoomed, there is no way to zoom out or reset the zoom because the web app overrides my pinch to zoom out. I am stuck with a viewport weirdly zoomed, the website is unusable and the only way I found to solve is to delete all site data in Firefox settings. Which is both unpractical as other data gets lost and most users ignore.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: Canvas2D' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Botond Ballo [:botond]]

As a workaround, Ctrl+0 (or menubar --> View --> Zoom --> Actual Size) should reset the pinch-zoom.

Comment 3

[Botond Ballo [:botond]]

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