Closed Bug 682618 Opened 8 years ago Closed 8 years ago
_contextmenu .html's Is Command Enabled calls can be dispatched to the wrong element
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?
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.
Attachment #559701 - Flags: review?(gavin.sharp)
Attachment #559701 - Flags: review?(gavin.sharp) → review+
Assignee: nobody → graememcc_firefox
OS: Linux → All
Hardware: x86_64 → All
Target Milestone: --- → Firefox 9
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
"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
You need to log in before you can comment on or make changes to this bug.