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 linux opt oth chunk, this test fails: 2789 INFO TEST-UNEXPECTED-FAIL | toolkit/content/tests/chrome/test_focus_anons.xul | correct number of blurs - got 0, expected 9 2790 INFO TEST-UNEXPECTED-FAIL | toolkit/content/tests/chrome/test_focus_anons.xul | correct number of focuses - got 0, expected 10

I am having a hard time reproducing this locally with a local build of linux64 opt. In the try push, I don't see this failing on linux64 opt, so maybe vaibhav can reproduce this on linux32 opt.

This test may just need a waitForFocus call, which it should have anyway.

I am also having linux64 locally, I will still see if this can be produced locally.

This failure still exists in recent times on linux32 opt and linux64 opt: https://treeherder.mozilla.org/#/jobs?repo=try&revision=44a1865965ce is there a place you can recommend putting waitforfocus: https://dxr.mozilla.org/mozilla-central/source/toolkit/content/tests/chrome/test_focus_anons.xul?from=test_focus_anons.xul&case=true#1 It appears that we would probably need this after each synthesizeKey call, sort of like this: https://dxr.mozilla.org/mozilla-central/source/toolkit/content/tests/chrome/test_focus_anons.xul?from=test_focus_anons.xul&case=true#66 Some other data, when it passes it takes ~1100ms, but when it fails it takes ~120ms. Maybe the waitforfocus will solve this, but maybe that will give us a clue. Do let me know if that is what you were thinking, we could try it out.

It would be needed in one place instead of the setTimeout.

looking good on try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=827aa3a16c1f with that amount of retriggers I would normally see 6-10 instances, now I see 0!