test_esc_key_closes_clears.xul fails intermittently on Linux

RESOLVED FIXED in mozilla1.9.2a1

Status

()

defect
RESOLVED FIXED
10 years ago
7 years ago

People

(Reporter: dietrich, Assigned: sdwilsh)

Tracking

({intermittent-failure, regression})

Trunk
mozilla1.9.2a1
x86
Linux
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

OS: Mac OS X → Linux
Whiteboard: [orange]
Quite often, when this happens, browser_ctrlTab.js fails as well (bug 498704).
Summary: test_esc_key_closes_clears.xul fails intermittently → test_esc_key_closes_clears.xul fails intermittently on Linux
This test uses synthesizeKey() to send events to the download window.
Even though synthesizeKey() takes a window as an argument, key events do not seem to get processed unless the toplevel window is active.  Is this a change from bug 178324, or was this always the behavior?

The test does not seem to wait for the download window to become active.

The failure seems 100% reproducible when running only this test
(python runtests.py --chrome --test-path=toolkit/mozapps/downloads/tests/chrome/test_esc_key_closes_clears.xul)
but I haven't seen it happen locally when running all the tests.
This didn't use to fail - it used to be super reliable :(
(In reply to comment #2)
> The test does not seem to wait for the download window to become active.
The test does wait for the window to finish building the list though..

What if the window was forced to be focused?

      let win = aSubject.QueryInterface(Ci.nsIDOMWindow);
+     win.focus();

http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/downloads/tests/chrome/test_esc_key_closes_clears.xul#85

?
Given http://hg.mozilla.org/mozilla-central/rev/704d14a04548 and the discussion in that bug, I bet that's it.
(we should probably fix any and all of our tests that make this assumption)
Posted patch v1.0Splinter Review
And fix all other tests while we are at it.
Assignee: nobody → sdwilsh
Status: NEW → ASSIGNED
Attachment #388329 - Flags: review?
Attachment #388329 - Flags: review? → review?(edilee)
Comment on attachment 388329 [details] [diff] [review]
v1.0

r=... hey wait! It's already there in the patch. :p

Kinda curious why we don't run in to them yet.. Any particular patterns in the ones that have caused oranges?
Attachment #388329 - Flags: review?(edilee) → review+
Not that I'm aware of - we fixed the one and then this one popped up.  *shrugs*

I probably didn't need to fix all of these files - only ones that do synthesizeKey stuff.  But, it's easier if all the tests are the same so that somebody doesn't copy and paste a bad test and it's missed in review.

http://hg.mozilla.org/mozilla-central/rev/a0f1f157a102
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
Depends on: 497839
Blocks: 178324, 438871
Depends on: 499438
Flags: in-testsuite+
Depends on: 506175
No longer depends on: 497839
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.