Created attachment 444282 [details] DOM event logger for wheel, touch, and gesture events. Despite gesturestart/gesturechange/gestureend all being defaultPrevented, the "pinch to zoom out to all tabs" browser gesture in Safari still fires occasionally. I've attached a test case and will annex a video repro for the bug.
Created attachment 444283 [details] Bug reproduction of 'pinch to tab overview' gesture
<rdar://problem/85681617>
I am able to reproduce this consistently in Safari 15.4 (17613.1.17.1.13) on macOS Monterey 12.3.1 on both M1 and Intel architecture MacBook Pros. It appears to be triggered when the gesture has both scale and rotation changes, but not when rotation stays constant while scale changes.
*** Bug 240892 has been marked as a duplicate of this bug. ***
From the dupe: (In reply to Jarod Gowgiel from comment #0) > When zooming out on a web page, Safari triggers a "Tab Expose" view as a > result of overscroll, and when scrolling backwards or forwards triggers > navigation. > > I'd expect that, similar to other gestures, calling preventDefault() on the > resulting GestureEnd would prevent these system gestures from occurring, but > that isn't the case. On iOS, it's a known workaround to preventDefault() on > the touchstart event that begins the gesture, but similar workarounds (like > preventDefault() on the mousedown) seem to not have the same effect on macOS > in Safari from my experimentation. > > As an alternate approach, I also tried out overscroll-behavior. The > specification for overscroll-behavior (which will be the [new default > soon](https://bugs.webkit.org/show_bug.cgi?id=236060) and that I > experimented with activating for myself locally via the "Experimental > Features") states that "[contain] indicates that the element must not > perform non-local boundary default actions such as scroll chaining or > navigation." Even when applying "overscroll-behavior: contain" to an > element, both of these non-local interactions (swiping backwards, and > pinching to zoom) are still triggered.
Also from the dupe: > When considering changes in this area, we need to keep in mind whether preventing standard browser behaviors is user friendly. It often isn’t.