1115088 - test_contextmenu_menugroup.xul fails when run as a standalone directory

Status: NEW

(Firefox :: Menus, defect)

Description

[Vaibhav (:vaibhav1994)]

in bug 1110982, we are looking to enable tests where we run a fresh browser instance per directory.  Usually what happens is that a few tests fail because they accidentally depend on the state of the browser from an earlier test.

In the try run:
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=1a5fa04f057a

In the linux opt/debug oth chunk, this test fails:

 2967 INFO TEST-UNEXPECTED-FAIL | toolkit/content/tests/widgets/test_contextmenu_menugroup.xul | two-down-keys event target ID a - got a, expected b 

 2968 INFO TEST-UNEXPECTED-FAIL | toolkit/content/tests/widgets/test_contextmenu_menugroup.xul | Test timed out. - expected PASS

Comment 1

[Joel Maher ( :jmaher ) (UTC -8)]

I am able to reproduce this easily on my local inbound build of linux64 opt by running:
./mach mochitest-chrome toolkit/content/tests/widgets/

Here is some of the output I get:
0 INFO SimpleTest START
1 INFO TEST-START | toolkit/content/tests/widgets/test_contextmenu_menugroup.xul
2 INFO TEST-PASS | toolkit/content/tests/widgets/test_contextmenu_menugroup.xul | Got the reference to the context menu 
3 INFO must wait for load
4 INFO TEST-PASS | toolkit/content/tests/widgets/test_contextmenu_menugroup.xul | one-down-key event type popupshowing fired 
5 INFO TEST-PASS | toolkit/content/tests/widgets/test_contextmenu_menugroup.xul | one-down-key event target ID context 
6 INFO TEST-PASS | toolkit/content/tests/widgets/test_contextmenu_menugroup.xul | one-down-key popupshowing state 
7 INFO TEST-PASS | toolkit/content/tests/widgets/test_contextmenu_menugroup.xul | one-down-key event type popupshown fired 
8 INFO TEST-PASS | toolkit/content/tests/widgets/test_contextmenu_menugroup.xul | one-down-key event target ID context 
9 INFO TEST-PASS | toolkit/content/tests/widgets/test_contextmenu_menugroup.xul | one-down-key popupshown state 
10 INFO TEST-PASS | toolkit/content/tests/widgets/test_contextmenu_menugroup.xul | one-down-key event type DOMMenuItemActive fired 
11 INFO TEST-PASS | toolkit/content/tests/widgets/test_contextmenu_menugroup.xul | one-down-key event target ID a 
12 INFO TEST-PASS | toolkit/content/tests/widgets/test_contextmenu_menugroup.xul | one-down-key item a active 
13 INFO TEST-PASS | toolkit/content/tests/widgets/test_contextmenu_menugroup.xul | two-down-keys event type DOMMenuItemInactive fired 
14 INFO TEST-PASS | toolkit/content/tests/widgets/test_contextmenu_menugroup.xul | two-down-keys event target ID a 
15 INFO TEST-PASS | toolkit/content/tests/widgets/test_contextmenu_menugroup.xul | two-down-keys event type DOMMenuItemActive fired 
16 INFO TEST-UNEXPECTED-FAIL | toolkit/content/tests/widgets/test_contextmenu_menugroup.xul | two-down-keys event target ID a - got a, expected b


Jaws, can you take a look at this?

Comment 2

[Jared Wein [:jaws] (please needinfo? me)]

I can't reproduce the failure on Windows 8. I guess it's linux only? I'll look at it on my Linux VM later.

Comment 3

[Joel Maher ( :jmaher ) (UTC -8)]

this does look to be linux specific.  I had reproduced it on linux64 opt.  Do ping in this bug or on irc if you have trouble reproducing it locally.

Comment 4

[Jared Wein [:jaws] (please needinfo? me)]

I can reproduce comment #1 on my Linux VM, but I also see failures when running the test by itself on both Linux and Windows. The failures are different though.

Comment #1 says that the target of the event is wrong, but for me on my Linux VM I get a hang after the first key-down. I'm pretty sure that this is the same error as comment #1 though, since this bug is really about the timeout.

However when running the test by itself, I don't see the same timeout on either platform. Instead there are extra events that are fired after the tests has finished. I'm curious if this is an issue with popup_shared.js.

I'll keep looking.

Comment 5

[Joel Maher ( :jmaher ) (UTC -8)]

:jaws, any more luck on this bug?

Comment 6

[Joel Maher ( :jmaher ) (UTC -8)]

We only have a few tests left, I would like to disable this test case for os=='linux' so we can move forward with --run-by-dir by the end of the week.

If we can hack on this test case, I would be happy to work on fixing this vs disabling it.

Comment 7

[Jared Wein [:jaws] (please needinfo? me)]

I haven't made any more progress on this bug and don't have the time to look in to it at the moment.