Created attachment 556311 [details] Testcase (Linux/Mac) test_contextmenu.html uses synthesizeMouse to send out a NS_CONTEXTMENU event, which causes display of the context menu. In constructing the context menu, various IsCommandEnabled calls are made to the command dispatcher. Ultimately, nsWindowRoot::GetControllers is called. However, this implicitly expects the target of the command to be focused. On Linux/Mac it isn't, so the contenteditable div, focused at test start, answers the IsCommandEnabled calls made by the context menus for the majority of elements tested. This doesn't happen on Windows, because of bug 682338, but when that bug is fixed the problem will switch from Linux/Mac to Windows. The attached testcase will currently work on Linux/Mac, and gives a general idea of the problem (though it too will be fixed by 682338). The problem in general doesn't happen in normal usage, as NS_CONTEXTMENU events don't occur in isolation - they're surrounded by NS_MOUSE_BUTTON_(DOWN|UP) events which perform the necessary focus/blurring of elements.
Can't we just focus the element manually during the test?
Created attachment 559701 [details] [diff] [review] Patch v1 [Checked in: Comment 4] We'll need to explicitly call blur too, as focus() can fail. For example, the focus call would fail for the img element, so the isCommandEnabled calls for the img would be dispatched to the previously focused element, which would be the input element.
"Backout changeset 987810fab278 to re-enable test_contextmenu on linux, which should no longer be flaky following the landing of bug 682618": https://hg.mozilla.org/mozilla-central/rev/f10597ebc79e