Closed Bug 611457 Opened 9 years ago Closed 9 years ago

mochitest-chrome: intermittent "test_bug607584.xul | Test timed out."

Categories

(Core :: DOM: Editor, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla5
Tracking Status
blocking2.0 --- Macaw+
status2.0 --- .1-fixed

People

(Reporter: sgautherie, Assigned: ehsan)

References

()

Details

(Keywords: intermittent-failure)

Attachments

(2 files)

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1289508092.1289509317.21925.gz
Rev3 Fedora 12 mozilla-central opt test mochitest-other on 2010/11/11 12:41:32
{
7085 ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/editor/libeditor/html/tests/test_bug607584.xul | Test timed out.
}
One possible reason for this failure could be that the document is loaded before we set its src attribute, which would cause the progress listener not fire because a new load is not initiated.  Setting src to an equivalent but different URI (such as data:text/html,) should fix this.
Assignee: nobody → ehsan
Status: NEW → ASSIGNED
Attachment #491722 - Flags: review?(roc)
Whiteboard: [orange] → [orange][needs landing]
http://hg.mozilla.org/mozilla-central/rev/900c9f516d53
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [orange][needs landing] → [orange]
Target Milestone: --- → mozilla2.0b8
Apparently not fixed after all, per comment 3 :-(  Reopening.
Status: RESOLVED → REOPENED
OS: Linux → All
Hardware: x86 → All
Resolution: FIXED → ---
Attachment #491722 - Attachment description: Patch (v1) → Patch (v1) [Checked in: Comment 2]
Another idea is that progressListener, which is supposed to handle the load of the iframe, is local to runTest, so in the unfortunate event that a gc runs after runTest has finished and before the iframe has loaded, that object could be collected prematurely.  I'd like to try this patch to see if it fixes the orange.
Attachment #518910 - Flags: review?(roc)
Comment on attachment 518910 [details] [diff] [review]
Patch (v2)
[Checked in: Comment 277 & 293]

Seems fine, but will it fix the bug? Are progress listeners weakly referenced?
Attachment #518910 - Flags: review?(roc) → review+
(In reply to comment #271)
> Comment on attachment 518910 [details] [diff] [review]
> Patch (v2)
> 
> Seems fine, but will it fix the bug? Are progress listeners weakly referenced?

Yep. AddProgressListener grabs a weak reference off of the argument and stores that.
http://hg.mozilla.org/mozilla-central/rev/4a58a3c4d046
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Attachment #518910 - Attachment description: Patch (v2) → Patch (v2) [Checked in: Comment 277]
(In reply to comment #278)
> http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1300122031.1300125743.2703.gz
> Rev3 Fedora 12 mozilla-central debug test mochitest-other on 2011/03/14
> 10:00:31

This one was just before check-in, so can be ignored.
Target Milestone: mozilla2.0b8 → mozilla2.0
(In reply to comment #280)
> http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1300123389.1300127118.9605.gz
> Rev3 Fedora 12 tryserver debug test mochitest-other on 2011/03/14 10:23:09

This one was just before check-in, so can be ignored too.
status2.0: --- → ?
Target Milestone: mozilla2.0 → mozilla2.2
Can we land this fix on the mozilla2.0 repo too, please?
blocking2.0: --- → Macaw
Attachment #518910 - Attachment description: Patch (v2) [Checked in: Comment 277] → Patch (v2) [Checked in: Comment 277 & 293]
(In reply to comment #294)
> http://tinderbox.mozilla.org/showlog.cgi?log=Firefox4.0/1301688766.1301692644.6310.gz
> Rev3 Fedora 12 mozilla-2.0 debug test mochitest-other on 2011/04/01 13:12:46

(In reply to comment #295)
> http://tinderbox.mozilla.org/showlog.cgi?log=Firefox4.0/1301690234.1301694083.12654.gz
> Rev3 Fedora 12 mozilla-2.0 debug test mochitest-other on 2011/04/01 13:37:14

Both before comment 293 fix.
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.