498805 - test_esc_key_closes_clears.xul fails intermittently on Linux

Status: RESOLVED FIXED

(Toolkit :: Downloads API, defect)

Description

[Dietrich Ayala (:dietrich)]

log: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1245190144.1245196971.30104.gz

Comment 1

[Dão Gottwald [:dao]]

Quite often, when this happens, browser_ctrlTab.js fails as well (bug 498704).

Comment 2

[Karl Tomlinson (:karlt)]

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.

Comment 3

[Shawn Wilsher :sdwilsh]

This didn't use to fail - it used to be super reliable :(

Comment 4

[(no longer active)]

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1247315227.1247317073.13525.gz

Comment 5

[Ed Lee :Mardak]

(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

?

Comment 6

[Shawn Wilsher :sdwilsh]

Given http://hg.mozilla.org/mozilla-central/rev/704d14a04548 and the discussion in that bug, I bet that's it.

Comment 7

[Shawn Wilsher :sdwilsh]

(we should probably fix any and all of our tests that make this assumption)

Comment 8

[Shawn Wilsher :sdwilsh]

Attachment: v1.0

And fix all other tests while we are at it.

Comment 9

[Ed Lee :Mardak]

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?

Comment 10

[Shawn Wilsher :sdwilsh]

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