You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I wrote a quick demo to see which pointer events and compatibility mouse events are fired in each mobile browser when long tapping on an <img>: https://output.jsbin.com/zeroqih
Below is what I found:
Desktop (FF mouse)
Firefox
Chrome
Safari (wtc: none)
Safari (wtc: default)
pointerover
pointerover
pointerover
pointerover
pointerover
pointerenter
pointerenter
pointerenter
pointerenter
pointerenter
pointerdown
pointerdown
pointerdown
pointerdown
pointermove
(pause)
pointermove
(pause)
(pause)
... (approx 20-50x)
pointermove
mouseover
mouseover
mouseover
mouseover
mouseover
mouseenter
mouseenter
mouseenter
mouseenter
mouseenter
mousemove
mousemove
mousemove
(RMB depressed)
pointerdown
mousedown
mousedown
mousedown
(pause until release)
(pause until release)
(pause)
pointerup
pointerup
mouseup
auxclick
contextmenu
contextmenu
contextmenu
pointercancel
pointercancel
pointercancel
pointerout
pointerout
pointerout
pointerout
pointerleave
pointerleave
pointerleave
pointerleave
mouseout
mouseleave
The notable differences from my pov are:
Safari for iOS never fires a contextmenu event, despite opening a very similar image-specific menu to the Android browsers (when -webkit-touch-callout is absent).
Both Android browsers fire a mousemove event but Safari for iOS always fires a mousedown event instead (although without a mouseup).
No matter how precisely you lower and raise your finger, Chrome for Android fires a bunch of pointermove events (I guess for pressure changes?), whereas Firefox for Android and Safari for iOS typically fire none unless you jiggle around your finger.
Are 1 and 2 in particular currently allowed by the spec, and in the working group's opinion, should they be?
I have a legacy site that for mouse input, currently shows a html tooltip when hovering over a custom button. To provide more reasonable behaviour for touch input, I figured I'd show the tooltip when the button is either panned over or long tapped. With the differences above, this proved way more difficult than I expected:
Cancelling the native context menu is handled by preventing the default action of an event or adding a CSS property in different browsers.
The events fired when the tap has been held long enough to become a long tap are different in different browsers.
Even after accounting for the above two factors, some browsers will then show the tooltip almost immediately at the start of the tap because they fire pointermove events that others don't, even when the user's finger is stationary and lifting it would trigger a click event on the button. Resolving this requires listening for a 4th event type and tracking state.
The text was updated successfully, but these errors were encountered:
I wrote a quick demo to see which pointer events and compatibility mouse events are fired in each mobile browser when long tapping on an
<img>
: https://output.jsbin.com/zeroqihBelow is what I found:
The notable differences from my pov are:
contextmenu
event, despite opening a very similar image-specific menu to the Android browsers (when-webkit-touch-callout
is absent).mousemove
event but Safari for iOS always fires amousedown
event instead (although without amouseup
).pointermove
events (I guess for pressure changes?), whereas Firefox for Android and Safari for iOS typically fire none unless you jiggle around your finger.Are 1 and 2 in particular currently allowed by the spec, and in the working group's opinion, should they be?
I have a legacy site that for mouse input, currently shows a html tooltip when hovering over a custom button. To provide more reasonable behaviour for touch input, I figured I'd show the tooltip when the button is either panned over or long tapped. With the differences above, this proved way more difficult than I expected:
pointermove
events that others don't, even when the user's finger is stationary and lifting it would trigger aclick
event on the button. Resolving this requires listening for a 4th event type and tracking state.The text was updated successfully, but these errors were encountered: