506850 - [MacOSX] mochitest-chrome: test_action_keys_respect_focus.xul reports "Test timed out"

Status: VERIFIED FIXED

(SeaMonkey :: Download & File Handling, defect)

Description

[Serge Gautherie (:sgautherie)]

Linux:
intermittent, like the first one:
{
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1247628113.1247635683.9985.gz
Linux comm-1.9.1 unit test on 2009/07/14 20:21:53
589 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/suite/common/downloads/tests/test_action_keys_respect_focus.xul | Test timed out.
650 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/suite/common/downloads/tests/test_clear_button_disabled.xul | Test timed out.
}
NB: They seem to always fail together ... Fix the former then see if the latter remains.

MacOSX:
first failure right after check-in, always since then:
{
http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey2.0&maxdate=1247590141&hours=12

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1247577181.1247583663.12463.gz
OS X 10.4 comm-central unit test on 2009/07/14 06:13:01
595 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/suite/common/downloads/tests/test_action_keys_respect_focus.xul | Test timed out.

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1247581807.1247588645.4066.gz
OS X 10.5 comm-1.9.1 unit test on 2009/07/14 07:30:07
591 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/suite/common/downloads/tests/test_action_keys_respect_focus.xul | Test timed out.
}

Windows:
(Seems to always pass)

Comment 1

[Serge Gautherie (:sgautherie)]

Fwiw, there are also intermittent:

{
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1248726256.1248733406.22466.gz
Linux comm-1.9.1 unit test on 2009/07/27 13:24:16

595 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/suite/common/downloads/tests/test_action_keys_respect_focus.xul | Test timed out.
665 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/suite/common/downloads/tests/test_delete_key_cancels.xul | [SimpleTest/SimpleTest.js, window.onerror] An error occurred: [ Components is not defined ]
670 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/suite/common/downloads/tests/test_enter_dblclick_opens.xul | [SimpleTest/SimpleTest.js, window.onerror] An error occurred: [ Components is not defined ]
673 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/suite/common/downloads/tests/test_multi_select.xul | [SimpleTest/SimpleTest.js, window.onerror] An error occurred: [ Components is not defined ]
}

and

{
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey2.0/1248730412.1248740258.1832.gz
OS X 10.5 comm-1.9.1 unit test on 2009/07/27 14:33:32

595 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/suite/common/downloads/tests/test_action_keys_respect_focus.xul | Test timed out.
665 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/suite/common/downloads/tests/test_delete_key_cancels.xul | [SimpleTest/SimpleTest.js, window.onerror] An error occurred: [ Components is not defined ]
670 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/suite/common/downloads/tests/test_enter_dblclick_opens.xul | [SimpleTest/SimpleTest.js, window.onerror] An error occurred: [ Components is not defined ]
673 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/suite/common/downloads/tests/test_multi_select.xul | [SimpleTest/SimpleTest.js, window.onerror] An error occurred: [ Components is not defined ]
721 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/suite/common/downloads/tests/test_space_key_retries.xul | [SimpleTest/SimpleTest.js, window.onerror] An error occurred: [ Components is not defined ]
}

Comment 2

[Serge Gautherie (:sgautherie)]

(In reply to comment #0)
> MacOSX:
> first failure right after check-in, always since then:
> .../test_action_keys_respect_focus.xul | Test timed out.

We should start be fixing (or at least working around) this permanent orange.

Can anyone (with a MacOSX) reproduce?

Comment 3

[Serge Gautherie (:sgautherie)]

Attachment: (Av1) Skip test 8 ftb

As discussed at meeting today, noone is expected to look at this on a Mac,
and I have no way to figure this out from the log.
Let's get rid of the permanent orange for now.

Comment 4

[Serge Gautherie (:sgautherie)]

Comment on attachment 393897 [details] [diff] [review]
(Av1) Skip test 8 ftb


Ah, will use a "todo(false," instead!

Comment 5

[[e-mail]]

Comment on attachment 393897 [details] [diff] [review]
(Av1) Skip test 8 ftb

>           // Clear List: Return (execute Clear List)
>           clearList.focus();
>           synthesizeKey("VK_RETURN", {}, win);
Hmm, is this a specific VK_RETURN test? I seem to remember seeing some Firefox checkins to eliminate VK_RETURN keys because they weren't reliable.

Comment 6

[[e-mail]]

Or maybe it's because the Mac doesn't allow the button to be focused without full keyboard accessibility - setting accessibility.tabfocus to 7 might help?

Comment 7

[Serge Gautherie (:sgautherie)]

Attachment: (Bv1) Need pref("accessibility.tabfocus", 7) on MacOSX (too) [Backout: See comment 19]

Per comment 6:
copied from some other test(s), obviously worth a try.

Comment 8

[[e-mail]]

(In reply to comment #7)
> copied from some other test(s), obviously worth a try.
Which one? (MXR link preferred)

Comment 9

[Serge Gautherie (:sgautherie)]

(In reply to comment #8)
> Which one? (MXR link preferred)

http://mxr.mozilla.org/comm-central/search?string=accessibility.tabfocus&case=on
http://mxr.mozilla.org/comm-central/source/mozilla/modules/libpref/src/init/all.js#161
http://mxr.mozilla.org/comm-central/source/mozilla/layout/forms/test/test_bug411236.html?force=1#27
http://mxr.mozilla.org/comm-central/source/mozilla/content/events/test/test_bug238987.html?force=1#34

Comment 10

[[e-mail]]

Comment on attachment 394075 [details] [diff] [review]
(Bv1) Need pref("accessibility.tabfocus", 7) on MacOSX (too)
[Backout: See comment 19]

>+  netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
This shouldn't be necessary for chrome (or browser-chrome) tests.

>+  if (!newValue) {
>+    try {
>+      prefs.clearUserPref("tabfocus");
>+    } catch(ex) {}
I'm sure we need this, but the code you pointed to doesn't have it and I can't work out why...
[It's a pity that Application.prefs doesn't allow you to clear one pref.]

Comment 11

[Serge Gautherie (:sgautherie)]

Comment on attachment 394075 [details] [diff] [review]
(Bv1) Need pref("accessibility.tabfocus", 7) on MacOSX (too)
[Backout: See comment 19]


http://hg.mozilla.org/comm-central/rev/3bf49c355cb2
Bv1, with comment 10 suggestion(s),
plus revised restoreTestedFunction().


(In reply to comment #10)
> >+  netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
> This shouldn't be necessary for chrome (or browser-chrome) tests.

Line removed. (I did do a dumb copy.)

> >+  if (!newValue) {
> >+    try {
> >+      prefs.clearUserPref("tabfocus");
> >+    } catch(ex) {}
> I'm sure we need this, but the code you pointed to doesn't have it and I can't
> work out why...

You sure? Both linked tests have the same (function) code, afaict...

Comment 12

[[e-mail]]

Sorry, my bad, I was looking on mozilla-central, not mozilla-1.9.1

Comment 13

[Serge Gautherie (:sgautherie)]

(In reply to comment #11)
> http://hg.mozilla.org/comm-central/rev/3bf49c355cb2

This (alone) did not help :-(


(In reply to comment #12)
> Sorry, my bad, I was looking on mozilla-central, not mozilla-1.9.1

Ah, right: bug 487059 removed the try+catch.

Comment 14

[[e-mail]]

This might be relevant:
http://mxr.mozilla.org/comm-central/source/mozilla/layout/xul/base/src/nsButtonBoxFrame.cpp#96
So skipping test 8 might be correct after all.
(But I don't like the way that attachment 393897 [details] [diff] [review] does it.)

Comment 15

[Serge Gautherie (:sgautherie)]

Attachment: (Cv1) clearListButton: use doCommand() instead of focus()+synthesizeKey("VK_RETURN"), to fix MacOSX

(In reply to comment #5)
> Hmm, is this a specific VK_RETURN test? I seem to remember seeing some Firefox

Iiuc, the test does want to test VK_RETURN on the download tree,
but it should not care how the button is triggered.

> checkins to eliminate VK_RETURN keys because they weren't reliable.

The (only) one I found is bug 507046 ;-)

(In reply to comment #14)
> This might be relevant:
> http://mxr.mozilla.org/comm-central/source/mozilla/layout/xul/base/src/nsButtonBoxFrame.cpp#96

Indeed, worth a try too.
(I'll try and back patch Bv1 out if this one works.)

Comment 16

[Serge Gautherie (:sgautherie)]

Attachment: (Cv1a) clearListButton: on MacOSX, use doCommand() instead of focus()+synthesizeKey("VK_RETURN") [Checkin: Comment 18]

Cv1, with workaround for MacOSX only.

(In reply to comment #15)
> but it should not care how the button is triggered.

Actually, the comment just above says it does :->

Comment 17

[[e-mail]]

Comment on attachment 394300 [details] [diff] [review]
(Cv1a) clearListButton: on MacOSX, use doCommand() instead of focus()+synthesizeKey("VK_RETURN")
[Checkin: Comment 18]

OK, let's give this a go.

Comment 18

[Serge Gautherie (:sgautherie)]

Comment on attachment 394300 [details] [diff] [review]
(Cv1a) clearListButton: on MacOSX, use doCommand() instead of focus()+synthesizeKey("VK_RETURN")
[Checkin: Comment 18]


http://hg.mozilla.org/comm-central/rev/d92aea117074

Comment 19

[Serge Gautherie (:sgautherie)]

Comment on attachment 394075 [details] [diff] [review]
(Bv1) Need pref("accessibility.tabfocus", 7) on MacOSX (too)
[Backout: See comment 19]


http://hg.mozilla.org/comm-central/rev/96b75d300c01

Comment 20

[Serge Gautherie (:sgautherie)]

MacOSX permanent orange is now fixed :-) (and 10.4 box back to green!)
Let's morph this bug to that issue only.

If(/when) the intermittent failures happen again, let's open a new bug.

Comment 21

[Serge Gautherie (:sgautherie)]

V.Fixed, per tinderboxes.

Comment 22

[Serge Gautherie (:sgautherie)]

(In reply to comment #20)
> If(/when) the intermittent failures happen again, let's open a new bug.

I filed bug 515407.