Last Comment Bug 682618 - test_contextmenu.html's IsCommandEnabled calls can be dispatched to the wrong element
: test_contextmenu.html's IsCommandEnabled calls can be dispatched to the wrong...
Status: RESOLVED FIXED
:
Product: Firefox
Classification: Client Software
Component: Menus (show other bugs)
: Trunk
: All All
: -- normal (vote)
: Firefox 9
Assigned To: Graeme McCutcheon [:graememcc]
:
: Jared Wein [:jaws] (please needinfo? me)
Mentors:
Depends on:
Blocks: 513558 46555 712871
  Show dependency treegraph
 
Reported: 2011-08-27 15:03 PDT by Graeme McCutcheon [:graememcc]
Modified: 2011-12-22 07:54 PST (History)
4 users (show)
bugzillamozillaorg_serge_20140323: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Testcase (Linux/Mac) (612 bytes, text/html)
2011-08-27 15:03 PDT, Graeme McCutcheon [:graememcc]
no flags Details
Patch v1 [Checked in: Comment 4] (1.57 KB, patch)
2011-09-10 09:27 PDT, Graeme McCutcheon [:graememcc]
gavin.sharp: review+
bugzillamozillaorg_serge_20140323: checkin+
Details | Diff | Splinter Review

Description Graeme McCutcheon [:graememcc] 2011-08-27 15:03:24 PDT
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.
Comment 1 :Ehsan Akhgari 2011-09-07 14:28:43 PDT
Can't we just focus the element manually during the test?
Comment 2 Graeme McCutcheon [:graememcc] 2011-09-10 09:27:55 PDT
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.
Comment 3 Graeme McCutcheon [:graememcc] 2011-09-20 09:15:38 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/812cea5c372e
Comment 4 Marco Bonardo [::mak] 2011-09-21 02:51:45 PDT
https://hg.mozilla.org/mozilla-central/rev/812cea5c372e
Comment 5 Ed Morley [:emorley] 2011-09-21 18:12:43 PDT
"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

Note You need to log in before you can comment on or make changes to this bug.