Closed Bug 508472 Opened 11 years ago Closed 11 years ago

intermittent failures in test_contextmenu.html | menuitem has an access key

Categories

(Firefox :: Menus, defect)

All
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 3.6b1

People

(Reporter: mstange, Assigned: enndeakin)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

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.
(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
Whiteboard: [orange]
(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.
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
Attachment #393018 - Flags: review?(dolske)
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?
Attachment #393018 - Flags: review?(dolske) → review+
http://hg.mozilla.org/mozilla-central/rev/fa6c850e3abd
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.6b1
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.