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=c1a0dea1e39c The failure occurs on linux opt, linux debug, linux asan and osx debug. The error is: 2829 INFO TEST-UNEXPECTED-FAIL | toolkit/content/tests/widgets/test_contextmenu_nested.xul | open inner popup event type DOMMenuItemInactive fired - got DOMMenuItemInactive, expected popupshowing 2830 INFO TEST-UNEXPECTED-FAIL | toolkit/content/tests/widgets/test_contextmenu_nested.xul | open inner popup event target ID outermenu - got outermenu, expected innermain 2831 INFO TEST-UNEXPECTED-FAIL | toolkit/content/tests/widgets/test_contextmenu_nested.xul | Test timed out. - expected PASS I see another related bug filed, which is Bug 931641

Regarding this, I assume this reproduces with: ./mach mochitest-chrome toolkit/content/tests/widgets I am working on downloading the linux64 asan build and trying to verify this locally.

downloading the build and tests packages for linux64 asan from the try push (http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/vaibhavmagarwal@gmail.com-c1a0dea1e39c/try-linux64-asan/), and running locally: python runtests.py --chrome --app ../firefox/firefox --xre-path ../firefox --utility-path ../bin --certificate-path ../certs --autorun --close-when-done --test-path toolkit/content/tests/widgets --extra-profile-file=../bin/plugins --console-level=INFO --setpref=webgl.force-enabled=true I am unable to reproduce this failure- linux asan didn't show this a lot, but 10 runs locally doesn't reproduce this. maybe linux32 debug or another platform would be more actionable.

This is still a problem: https://treeherder.mozilla.org/#/jobs?repo=try&revision=6afd882a7f34 we see this on linux*, of course on linux64 opt I couldn't reproduce this.

I could reproduce this on a linux32 vm and it reproduces pretty much every time. What is interesting is this test case is the first to run- which means the browser probably hasn't done all the initialization bits that it normally would. changing: https://dxr.mozilla.org/mozilla-central/source/toolkit/content/tests/widgets/popup_shared.js?from=popup_shared.js&case=true#57 from: goNext(); to: setTimeout(goNext, 2000); yields success over and over, changing it to a 1 second timeout yields failure. This tells me we need to make this test wait on some type of initialization routine. Although who knows!

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.

clearing the needinfo here