Open Bug 1115088 Opened 10 years ago Updated 2 years ago

test_contextmenu_menugroup.xul fails when run as a standalone directory

Categories

(Firefox :: Menus, defect)

All
Linux
defect

Tracking

()

People

(Reporter: vaibhav1994, Unassigned)

References

Details

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
Blocks: 1110982
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?
Flags: needinfo?(jaws)
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.
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.
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.
Flags: needinfo?(jaws)
:jaws, any more luck on this bug?
Flags: needinfo?(jaws)
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.
I haven't made any more progress on this bug and don't have the time to look in to it at the moment.
Flags: needinfo?(jaws)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.