Define interactions with contextmenu event?

[RByers]

Now that the spec is relatively explicit about the mouse events to expect on a tap, perhaps we should also say something about contextmenu?

In particular, Mobile Safari and Firefox don't generate any mouse* events prior to a touch-derived contextmenu but Chrome does. IIRC we did this in Chrome just to be consistent with the approach used for click - simulating the full event sequence you'd get with a real mouse. But perhaps this isn't worth it for contextmenu (which also isn't preceded by mouse events when triggered by the keyboard). If there's reason to believe it's sufficiently web compatible, then I'd support removing generation of the mouse* events from Chrome. @dtapuska WDYT?

[staktrace]

I concur that we should not be firing synthentic mouse events for touch-derived contextmenu events, unless there's a webcompat reason to do it.

[patrickhlauke]

I agree that for contextmenu no further compat events should be fired. Should the whole touch in fact be cancelled? (related, see what I consider a bug in iOS https://www.youtube.com/watch?v=oggIAZ9uHug relating to the native context menu)

[staktrace]

I'm assuming that by "whole touch be cancelled" you mean sending the touchcancel event to content. Chrome doesn't appear to be doing that, although Firefox does on Android. In fact Firefox does it on Android even if we get a browser context menu showing up (as opposed to just if web content does preventDefault() on the contextmenu event). On Windows the browser context menu only shows up on lifting the finger, after touchend is fired, so that's a moot scenario there. I'm in the process of implementing our touch-derived contextmenu for Windows, so coming to a consensus on this now would be quite timely :)

[staktrace]

Sorry, I was wrong. Chrome on Android does actually send the touchcancel to content, if the browser context menu shows up, but not if web content does preventDefault() on the contextmenu.

[karlcow]

There's a dicussion currently going on for Firefox on Android similar to this issue
https://bugzilla.mozilla.org/show_bug.cgi?id=1481923

[karlcow]

This stackoverflow tries to list the type of events being sent by different browsers.

[karlcow]

Using https://codepen.io/webcompat/pen/gOmRKee
On Mobile

• Firefox Nightly 90.0a1 Build #2015812491
• Chrome Canary 92.0.4506.0
• Safari 14.1

Firefox

• touchstart
• contextmenu (no vibration)
• touchcancel

Chrome

• touchstart
• contextmenu (vibration)
• touchend

Safari

• touchstart
• (text selection is showed then removed + vibration. no contextmenu event)
• touchend

[patrickhlauke]

Part of the issue here is also that Apple/WebKit are not engaging with this spec (so are unlikely to change their implementation based on what is decided here), and for the most part other browsers are now focusing more on Pointer Events. So I'm not sure if there's any more momentum here other than somehow document divergence and warning that "there be dragons"

[HolgerJeromin]

There's a dicussion currently going on for Firefox on Android similar to this issue
https://bugzilla.mozilla.org/show_bug.cgi?id=1481923

Just a sidenote: The issue in FF was solved.