Renable test for chrome://mochikit/content/a11y/accessible/test_name_nsRootAcc.xul | Test timed out.

RESOLVED FIXED in mozilla13

Status

()

Core
Disability Access APIs
P2
normal
RESOLVED FIXED
7 years ago
6 years ago

People

(Reporter: Mardak, Assigned: surkov)

Tracking

Trunk
mozilla13
x86
Windows XP
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fixed by bug 719754] b4)

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
The test was disabled after bug 574217 landed due to timeouts and previous failures bug 525175 and bug 542726

Updated

7 years ago
Blocks: 586788

Updated

7 years ago
Whiteboard: b4
Created attachment 465455 [details] [diff] [review]
Patch to disable test, v.1
[Checked in: Comment 7]

Disable the test on all platforms.
Any reason why we did see this failure when playing on maple?
More detail on the disabling:

Looks like this test has a history of timeouts (bug 525175 on Linux, and bug 542726 for SeaMonkey), though this seems to have gone perma-orange on Windows after TabCandy (bug 574217) landed.

The test itself looks a bit questionable...

test_name_nsRootAcc.xul is really just a stub for opening a new window containing name_nsRootAcc_wnd.xul, which is where the interesting parts of the test happen. It has a <tabbrowser> and <tabs>, and is simulating switching between to tabs in this window. The sketchy part is in switchTabSelectChecker(), where is seems to be constructing a fake event, and doTest() constructing some kind of event queue with it.

This all seems very odd to me, I'd expect just plain old tab eventListeners to detect tab selection changes at the right time, and that seems absent.

It's not entirely clear _exactly_ why this is failing -- did TabCandy cause a real behavioral change here, or just a timing change? The TabCandy and A11Y team should sort this out ASAP -- but given the history and inspection of the test I think it's reasonable to disable it while that investigation happens.

Log spew from an example failure:

From http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1281651814.1281653094.18428.gz&fulltext=1#err4

11283 INFO TEST-START | chrome://mochikit/content/a11y/accessible/test_name_nsRootAcc.xul
11284 INFO TEST-INFO | chrome://mochikit/content/a11y/accessible/test_name_nsRootAcc.xul | before wait for focus -- loaded: complete active window: ([object ChromeWindow]) chrome://browser/content/browser.xul focused window: ([object XPCNativeWrapper [object Window]]) chrome://mochikit/content/a11y/accessible/test_name_nsRootAcc.xul desired window: ([object Window]) chrome://mochikit/content/a11y/accessible/test_name_nsRootAcc.xul child window: ([object XPCNativeWrapper [object Window]]) chrome://mochikit/content/a11y/accessible/test_name_nsRootAcc.xul docshell visible: true
11285 INFO TEST-INFO | chrome://mochikit/content/a11y/accessible/test_name_nsRootAcc.xul | already focused
11286 INFO TEST-INFO | chrome://mochikit/content/a11y/accessible/test_name_nsRootAcc.xul | maybe run tests <load:true, focus:true> -- loaded: complete active window: ([object ChromeWindow]) chrome://browser/content/browser.xul focused window: ([object XPCNativeWrapper [object Window]]) chrome://mochikit/content/a11y/accessible/test_name_nsRootAcc.xul desired window: ([object Window]) chrome://mochikit/content/a11y/accessible/test_name_nsRootAcc.xul child window: ([object XPCNativeWrapper [object Window]]) chrome://mochikit/content/a11y/accessible/test_name_nsRootAcc.xul docshell visible: true
11287 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/a11y/accessible/test_name_nsRootAcc.xul | Test timed out.
11288 INFO SimpleTest finished chrome://mochikit/content/a11y/accessible/test_name_nsRootAcc.xul in 318868ms
(In reply to comment #2)
> Any reason why we did see this failure when playing on maple?

Mardak says this was indeed orange on the maple runs, but was just somehow overlooked.

Updated

7 years ago
Priority: -- → P3

Updated

7 years ago
Priority: P3 → P2
Could this be related to the use of TabView in tabbrowser.xml? Has the if (TabView && TabView...) pattern actually been tested? Looks like it would fail with TabView not being defined.

Updated

7 years ago
Blocks: 574217
No longer depends on: 574217
(In reply to comment #5)
> Could this be related to the use of TabView in tabbrowser.xml? Has the if
> (TabView && TabView...) pattern actually been tested? Looks like it would fail
> with TabView not being defined.

I was thinking that too... shouldn't it be if (window.TabView && TabView...)?

I can make the change, but don't have a Windows dev environment to test in. Perhaps push to maple?
No longer blocks: 586788
Target Milestone: --- → mozilla2.0
Comment on attachment 465455 [details] [diff] [review]
Patch to disable test, v.1
[Checked in: Comment 7]

http://hg.mozilla.org/mozilla-central/rev/dd73091a6315
Attachment #465455 - Attachment description: Patch to disable test, v.1 → Patch to disable test, v.1 [Checked in: Comment 7]
Whiteboard: b4 → [test is disabled] b4
Comment on attachment 465455 [details] [diff] [review]
Patch to disable test, v.1
[Checked in: Comment 7]

>+      // Actually, just disable this test everywhere -- bug 586818.

A |todo(false, ...)| would be better than a comment...

>+      SimpleTest.finish();
>+      return;
>+
>       if (LINUX) {
>         todo(false, "Enable test on Linux - see bug 525175.");
>         SimpleTest.finish();
Depends on: 633725
(In reply to comment #8)
> >+      // Actually, just disable this test everywhere -- bug 586818.
> 
> A |todo(false, ...)| would be better than a comment...

Done in bug 633725.
(Assignee)

Comment 10

6 years ago
fixed by bug 719754
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: mozilla2.0 → mozilla13
Depends on: 719754
No longer depends on: 525175
Flags: in-testsuite-
Whiteboard: [test is disabled] b4 → [fixed by bug 719754] b4
Assignee: nobody → surkov.alexander
You need to log in before you can comment on or make changes to this bug.