Created attachment 381520 [details] Pinch zoom fires mouse click event if both fingers are lifted simultaneously Safari 13.0.1 (605.1.15) on iOS Catalina fires an artificial mouse click event after a pinch zoom gesture if both fingers are lifted simultaneously. This is important, because if they are lifted sequentially, no mouse event is fired afterwards. So this results in the following event order when logged (from newest to oldest): MOUSEUP (evt.buttons = 0, evt.button = 0) MOUSEDOWN (evt.buttons = 0, evt.button = 0) // <<--- no buttons pressed, but mouse down? MOUSEENTER (evt.buttons = 0, evt.button = 0) POINTERUP // pinch gesture finished POINTERUP POINTERDOWN POINTERDOWN // pinch gesture start This can be reproduced with the attached HTML page which has a DIV element that listens for these events and logs them onto the page. Pinching in the rectangle yields the above log. First of all, why does it even fire mouse events when the fingers are lifted simultaneously? The second and even more unexpected part about this: The buttons state doesn't make sense, i.e., a mouse down event without any buttons pressed? Besides the attached reproduction, we have a running application (https://live.yworks.com/demos/style/templatestyles/index.html) that handles both, touch and mouse input, and may get stuck after a pinch gesture due to these unexpected mouse events.
Adding a mouse click listener to the attachment will also show that there is actually a mouse click event after the MOUSEDOWN and MOUSEUP. Also logging the coordinates shows that it will click somewhere between the POINTERDOWN locations. For reference, I've added another reproduction HTML with those additional coordinate logs and click listener.
Created attachment 381527 [details] Additionally log coordinates and mouse click events
If you really need to send artificial mouse events after a pinch gesture (which I would vote against), it should follow some common standard. Not all user agents do this, and if they do (and developers can't disable these events or distinguish real events from synthetic events), they would need to be at least consistent, i.e. if a button is reported to be pressed down, the "buttons" field should reflect that state. And it should happen either always or never. Right now it only happens if you manage to lift your two fingers at pretty much *exactly* the same millisecond, so it's hard to reproduce consistently for some people. The fact that this only happens sporadically from a user's point of view, clearly indicates to me that this is a bug in the browser, and I think I haven't seen this problem in older versions of Safari (11?), so this is a regression that breaks JS code in some websites and apps (like mine) where after a pinch, sometimes a (mouse-) action gets triggered, erroneously. Until this gets fixed, is there a way to unambiguously classify these mouse events as synthetic events so that developers can filter these bogus events?
<rdar://problem/56557520>
There’s no way we should be firing a synthetic click in this case, for sure. And, I can reproduce.
Thanks, Tim! Do you see a way for developers to identify these bogus events, now? I guess the timing of the events is telling: if the mouse events happens within fractions of a second after a pointer-up, they are very unlikely to be "real" events. Also of course the broken evt.buttons state looks telling. But maybe there is a better way? How would you detect these bogus events in order to ignore them? We need to implement a workaround for this into our library because right now in our customers' apps this UA behavior is triggering actions that should not trigger.
Although this bug is still open, I'm no longer able to reproduce it in iPadOS 15.2.1. Can someone link the related/duplicate issue that solved this problem, please?