Closed Bug 562328 Opened 15 years ago Closed 13 years ago

test_frames.html depends on SimpleTest.waitForFocus(), which makes the test timing-sensitive

Categories

(Core :: Disability Access APIs, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla8

People

(Reporter: hsivonen, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: intermittent-failure)

Attachments

(1 file, 1 obsolete file)

http://mxr-test.konigsberg.mozilla.org/mozilla-central/source/accessible/tests/mochitest/states/test_frames.html?force=1 calls addA11yLoadEvent which in turn calls SimpleTest.waitForFocus(). SimpleTest.waitForFocus() doesn't really do what it's advertised to do, so the test as a whole becomes timing-sensitive. See bug 554873.
Depends on: 554873
I tried to call addA11yLoadEvent from onload, which has worked in the past for working around waitForFocus brokenness, but that simple approach doesn't work here.
Attached patch Disable test_frames.html (obsolete) (deleted) — — Splinter Review
In case a real fix isn't available by Monday, I suggest disabling this test so that the HTML5 parser can be enabled.
Attachment #442372 - Flags: review?(jst)
I think it is really important to get the HTML5 parser turned on by default so that we can catch and triage other bugs that we don't know about (or cover in our mochitests). So yes, please simply disable this test with your landing (unless this bug is fixed). Henri, just out of interest, do you know what is different about the html5 parser that is more frequently exposing the weakness of SimpleTest.waitForFocus? Does the problem still occur when the parser is on the main thread?
(In reply to comment #7) > I think it is really important to get the HTML5 parser turned on by default so > that we can catch and triage other bugs that we don't know about (or cover in > our mochitests). So yes, please simply disable this test with your landing > (unless this bug is fixed). Thanks. > Henri, just out of interest, do you know what is different about the html5 > parser that is more frequently exposing the weakness of > SimpleTest.waitForFocus? The timing of things may differ a little, so the moment when the docshell navigates away from about:blank can be different relative to other asynchronous things that are going on. > Does the problem still occur when the parser is on the main thread? This particular test works for me locally and on the tryserver. It failed only on the real tinderbox where the the freedom to experiment with the single-threaded mode isn't available.
Attached patch Disable test_frames.html, with comment (deleted) — — Splinter Review
Attachment #442372 - Attachment is obsolete: true
Attachment #443053 - Flags: review?(roc)
Attachment #442372 - Flags: review?(jst)
Whiteboard: [orange] → [orange][test disabled]
I enabled tests as part of bug 638106, it sounds they don't fail anymore.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
sorry it should be worksforme, these tests never were dependent on SimpleTest.waitForFocus() explicitly, at least no more than other a11y tests, a11y in fx4 is not so sensible to timing issues so I assume the original problem has gone.
Resolution: FIXED → WORKSFORME
Whiteboard: [orange][test disabled] → [orange]
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Bug 676213 is a fix for this bug because nsDocAccessible::mContent is not updated (see patch of bug 638106) yet what means the document tree is not created at this point, so that the test is running too early.
Depends on: 676213
fixed by bug 676213 (mozilla 8), please reopen if you see the issue
Status: REOPENED → RESOLVED
Closed: 14 years ago13 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla8
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: