Summary: | Pinch zoom fires mouse click event with wrong evt.buttons state | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | fabian.schwarzkopf | ||||||
Component: | UI Events | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | NEW --- | ||||||||
Severity: | Normal | CC: | dino, graouts, mail, seb.p.mueller, thorton, webkit-bug-importer, wenson_hsieh | ||||||
Priority: | P2 | Keywords: | InRadar | ||||||
Version: | Safari 13 | ||||||||
Hardware: | iPhone / iPad | ||||||||
OS: | iOS 13 | ||||||||
Attachments: |
|
Description
fabian.schwarzkopf
2019-10-22 00:49:51 PDT
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? 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? |