Closed Bug 1115084 Opened 7 years ago Closed 7 years ago

test_focus_anons.xul fails when run as a standalone directory

Categories

(Core :: XUL, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla38

People

(Reporter: vaibhav1994, Assigned: jmaher)

References

Details

Attachments

(1 file)

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
Blocks: 1110982
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.
Flags: needinfo?(vaibhavmagarwal)
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.
Flags: needinfo?(vaibhavmagarwal)
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.
Flags: needinfo?(enndeakin)
It would be needed in one place instead of the setTimeout.
Flags: needinfo?(enndeakin)
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!
Assignee: nobody → jmaher
Status: NEW → ASSIGNED
Attachment #8554563 - Flags: review?(enndeakin)
Attachment #8554563 - Flags: review?(enndeakin) → review+
https://hg.mozilla.org/mozilla-central/rev/83b51c132519
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
You need to log in before you can comment on or make changes to this bug.