Consider sending a touchcancel event if the context menu is opened (i.e. not preventDefaulted) rather than not opening the context menu on Linux (and Mac)
Categories
(Core :: Panning and Zooming, task, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox116 | --- | fixed |
People
(Reporter: hiro, Assigned: hiro)
References
Details
Attachments
(2 files)
Historically on Linux and Mac we send a touchcancel event when we process a long-tap event and the contextmenu event was preventDefaulted. (Note that here is a test case)
But that's opposed to my intuitive. If a site author uses preventDefault() in contextmenu event handlers, it means to avoid opening context menus and the site wants to keep handle subsequent touch events?
In fact on Chrome's RDM on Linux a touchcancel event is fired when the context menu is opened via a long-tap. If the contextmenu event was preventDefaulted, no touchcancel event occurs.
| Assignee | ||
Comment 1•2 years ago
|
||
I am going to fix this prior to bug 1719855, since without fixing this bug 1719855 is pretty confusing.
| Assignee | ||
Comment 2•2 years ago
|
||
mouselongtap events are internally used for accessible caret on desktops.
Whether to fire a touchcancel event here should just depend on whether a context
menu opens or not.
| Assignee | ||
Comment 3•2 years ago
|
||
The modified test, helper_long_tap.html, is mostly now same as the Android one.
A difference is on the Linux/Mac version we observe a mouselongtap event after a
contextmenu event wasn't preventDefaulted.
Depends on D180636
Updated•2 years ago
|
Comment 5•2 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/ed3317e79644
https://hg.mozilla.org/mozilla-central/rev/45b3685dc883
Description
•