Open
Bug 477409
Opened 14 years ago
Updated 4 months ago
make reftest check its own timeout invariants
Categories
(Testing :: Reftest, defect)
Testing
Reftest
Tracking
(Not tracked)
NEW
mozilla1.9.2a1
People
(Reporter: dbaron, Unassigned)
References
Details
Attachments
(2 files, 1 obsolete file)
2.31 KB,
patch
|
jruderman
:
review+
|
Details | Diff | Splinter Review |
2.18 KB,
patch
|
jruderman
:
review+
|
Details | Diff | Splinter Review |
There have been a lot of correlated load failures on tinderbox lately, so I'm beginning to wonder if there's something wrong with the reftest harness's handling of its load failure timeouts. Here's a patch that makes it issue an unexpected failure report if it detects that something has gone wrong with its timeouts.
Attachment #361076 -
Flags: review?(jruderman)
Reporter | ||
Comment 1•14 years ago
|
||
(Note that there could also be interaction with the slow script dialog involved. sayrer says mochitest disables it through automation.py. Maybe we'll want the same once ted's patch in bug 468913 lands.)
Updated•14 years ago
|
Attachment #361076 -
Flags: review?(jruderman) → review+
Comment 2•14 years ago
|
||
Other ideas: * OnDocumentLoad could complain if there is not an outstanding timer. * The "if (gClearingForAssertionCheck)" bit might need to be moved down before the "Ignore load events for previous documents" bit. * The "Ignore load events for previous documents" bit could output some "NOISE:" explaining what it thinks is going on. * When contentRootElement is null, it should probably do something sane.
Reporter | ||
Comment 3•14 years ago
|
||
I pushed the existing patch as http://hg.mozilla.org/mozilla-central/rev/29bc88a2d670 . I'll try to write a patch for some of those other ideas soon...
Comment 4•14 years ago
|
||
Here's an example of a pair failure from today: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1234205896.1234211217.21332.gz#err0
Reporter | ||
Comment 5•14 years ago
|
||
This is equivalent to: (In reply to comment #2) > * The "if (gClearingForAssertionCheck)" bit might need to be moved down before > the "Ignore load events for previous documents" bit. but simpler, and I think it could be the fix for the cause of our double-timeouts lately.
Attachment #361591 -
Flags: review?(jruderman)
Comment 6•14 years ago
|
||
"but about:blank is unlikely to take a really long time to load" I'm not sure how to convince myself that this is the only way to get here with the URL being about:blank. And we're skeptical enough that about:blank *could* be taking a long time to load. How about using a unique URL for the clearing, like data:text/html,<!-- CLEAR -->
Reporter | ||
Comment 7•14 years ago
|
||
Good idea.
Attachment #361591 -
Attachment is obsolete: true
Attachment #361613 -
Flags: review?(jruderman)
Attachment #361591 -
Flags: review?(jruderman)
Updated•14 years ago
|
Attachment #361613 -
Flags: review?(jruderman) → review+
Reporter | ||
Comment 8•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/a82e37fed714
Comment 9•14 years ago
|
||
Is there any reason not to land this on m-1.9.1?
Reporter | ||
Updated•2 years ago
|
Assignee: dbaron → nobody
Status: ASSIGNED → NEW
Updated•4 months ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•