Bug 177911 – REGRESSION (Safari 11): Custom context menu does not receive mouse events after native menu has opened

• Component: UI Events
• Status: RESOLVED WORKSFORME

[Andrew Herron]

Created attachment 322761 [details]
video of bug in textbox.io and tinymce

This sounds similar to bug 29819 but I think it's subtly different. Our use case also works in Safari 10; this is a new bug in Safari 11.

I've attached a video to help show the issue, which also shows how the effect persists across tabs. Description of replication case:

* load https://textbox.io
* right click inside the editor on a misspelt word
* note the custom context menu works
* right click somewhere else on the page (doesn't have to be within the editor) to show the native context menu
* dismiss the native menu
* right click on the misspelt word again

The custom context menu is now non-interactive.

Alternative replication:

* load https://www.tinymce.com
* the editor overrides the context menu in all cases, so it's much easier to show the custom menu. Right click anywhere inside the editor.
* right click outside the editor to show the native menu
* right click inside the editor again (it takes two tries to replicate in the video, usually it's immediate)

When replicated, the mouse seems to behave as if the custom menu (content inside a floating div) doesn't exist. The cursor remains related to the text content behind it, and mouse move / click events are not received by the menu. The editor handling of clicks is slightly different, so while textbox.io does dismiss the menu on click that's a generic content click handler not menu activation. TinyMCE seems to ignore the first click and at that point the menu is interactive.

For both editors, regular menus that use the same code and DOM structure still work correctly; this is unique to context menus where we've used `preventDefault` to show our own UI.

I've tried this on a few machines, and not all of them exhibit the issue:

* yes - 13" MacBook Pro (2016), macOS 10.13.1 beta (17B25c), Safari 11.0.1 (13604.3.1)
* yes - 13" MacBook Pro (2016), macOS 10.13.1 beta (17B25c), Safari Tech Preview Release 41 (Safari 11.1, WebKit 13605.1.8)
* yes - 11" MacBook Air (early 2015), macOS 10.12.6, Safari 11.0 (12604.1.38.1.7)
* no  - 27" iMac (2010), macOS 10.12.6, Safari 11.0 (12604.1.38.1.7)
* no - Safari 10 on various machines

I can't check webkit nightly here as I'm running 10.13; I could try on the other machines but the behaviour isn't consistent so I thought I'd log this first and see if you need more information to replicate the problem.

I can build a standalone replication case if necessary but there's a lot of moving parts with these menus so it might take a while.

[Lucas Forschler]

Mass move bugs into the DOM component.

[Andrew Herron]

Can't reproduce it anymore