This test was failing with the same error messages on two different machines at the same time: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1249428308.1249431548.24511.gz http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1249429087.1249431331.21990.gz The failure is clearly not related to the checkin and the mochitest box has already gone green again. I haven't seen this failure before bug 505562 - might that have caused it?

Hmm, it's failing in test #2, which should be a context menu for plain text on a page. There are spelling suggestion menu entries appearing, which shouldn't be happening. Seems like either something is mistakenly enabling these entries for text on a page, or the context menu thinks it's for the text field on the test page (which shouldn't have "check spelling", so that would have to be enabled too). I'm not quite sure how this could be happening, it actually looks like a legitimate failure. Maybe something else is randomly leaving messy state?

> There are spelling suggestion menu entries appearing, which shouldn't > be happening. Sounds like bug 342675! That bug has 13 dups but no steps to reproduce.

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1249489197.1249492108.25145.gz WINNT 5.2 mozilla-central unit test on 2009/08/05 07:41:24

(In reply to comment #1) > I'm not quite sure how this could be happening, it actually looks like a > legitimate failure. Maybe something else is randomly leaving messy state? I think it's actually that the context menu isn't being initialized at all. The target is being set to the document when it fails rather than finding the right element. Running the test after a timeout makes it work fine though.

Do you need an actual timeout, or is |executeSoon| enough? (The latter is preferred to explicit setTimeout calls in tests.)

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1249506788.1249512433.26392.gz Linux mozilla-central talos on 2009/08/05 14:19:03

(In reply to comment #6) > Linux mozilla-central talos on 2009/08/05 14:19:03 Er, OS X 10.5.2 mozilla-central unit test on 2009/08/05 14:13:08.

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1249520627.1249522066.1079.gz OS X 10.5.2 mozilla-central test mochitests on 2009/08/05 18:03:47 54 failures starting with: 713 ERROR TEST-UNEXPECTED-FAIL | /tests/browser/base/content/test/test_contextmenu.html | menuitem has an access key

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1249540659.1249543674.5953.gz OS X 10.5.2 mozilla-central unit test on 2009/08/05 23:37:39

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1249577754.1249580783.8952.gz OS X 10.5.2 mozilla-central unit test on 2009/08/06 09:55:54

(In reply to comment #4) > (In reply to comment #1) > > I'm not quite sure how this could be happening, it actually looks like a > > legitimate failure. Maybe something else is randomly leaving messy state? > > I think it's actually that the context menu isn't being initialized at all. > > The target is being set to the document when it fails rather than finding the > right element. Running the test after a timeout makes it work fine though. Did you have a patch in mind? This seems to be happening a lot.

The reason for the delay seems to be that painting has not has occured. The window is laid out so coordinates are calculated properly but the mouse event hittesting requires the elements to be drawn on screen This patch waits for both the MozAfterPaint and load events to occur. I'm going to test this patch out to see.

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1249607934.1249609400.18217.gz OS X 10.5.2 mozilla-central test mochitests

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1249639068.1249640626.6548.gz OS X 10.5.2 mozilla-central test mochitests

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1249729613.1249732722.19329.gz OS X 10.5.2 mozilla-central unit test on 2009/08/08 04:06:53

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1249752312.1249753769.32730.gz OS X 10.5.2 mozilla-central test mochitests on 2009/08/08 10:25:12

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1249769074.1249774953.3859.gz OS X 10.5.2 mozilla-central unit test on 2009/08/08 15:04:34 http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1249770969.1249774334.29587.gz OS X 10.5.2 mozilla-central unit test on 2009/08/08 15:36:09 http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1249770970.1249772442.9198.gz OS X 10.5.2 mozilla-central test mochitests on 2009/08/08 15:36:10

Comment on attachment 393018 [details] [diff] [review] wait for paint and load Seems harmless enough. Does this mean, though, that a user could get unlucky and click a window after it's loaded but before it's painted? Or is that time delta going to be so tiny that it's impossible to hit in practice?

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1249924422.1249927629.931.gz OS X 10.5.2 mozilla-central unit test on 2009/08/10 10:13:42

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1249948303.1249949778.18233.gz OS X 10.5.2 mozilla-central test mochitests on 2009/08/10 16:51:43

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1249953120.1249960025.2474.gz OS X 10.5.2 mozilla-central unit test on 2009/08/10 18:12:00

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1249960817.1249962276.27544.gz OS X 10.5.2 mozilla-central test mochitests on 2009/08/10 20:20:17

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1249959129.1249963337.6791.gz OS X 10.5.2 mozilla-central unit test on 2009/08/10 19:52:09

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1249959750.1249963910.12943.gz OS X 10.5.2 mozilla-central unit test on 2009/08/10 20:02:30