Closed Bug 486556 Opened 11 years ago Closed 11 years ago
random orange in test
_delay _load .html
On mozilla-central we had a random orange on "Linux mozilla-central unit test" at 07:18 on 2009-04-02: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1238681884.1238687267.14373.gz *** 27850 ERROR TEST-UNEXPECTED-FAIL | /tests/content/media/video/test/test_delay_load.html | onload was not delayed until after metadataloaded - got 4, expected 5
It happened earlier as well: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1238651535.1238660997.14928.gz http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1238658738.1238667257.28183.gz (every time on Linux)
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1239180376.1239186312.26222.gz Linux mozilla-central unit test on 2009/04/08 01:46:16
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1239216044.1239225107.9145.gz (Linux mozilla-central)
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1239293753.1239299908.17826.gz Linux mozilla-central unit test
I can reproduce this in my Linux opt build. Yay!
Assignee: nobody → roc
The test is probably failing because of this sequence: 1) nsHTMLMediaElement::FirstFrameLoaded posts an asynchronous loadeddata event 2) nsHTMLMediaElement::FirstFrameLoaded then calls UnblockOnload(PR_FALSE); the load delay count is decremented, but let's suppose there's still something blocking the load, so the load delay count is now 1 3) that other thing stops delaying the load (probably via an event that was posted before step 1) and calls UnblockOnload(PR_TRUE) since it can fire onload synchronously 4) The load delay count is now zero so we fire onload synchronously 5) the loadeddata event posted in step 1 has not yet fired so the test fails As it stands, the spec doesn't actually prohibit this as far as I know, so we should change the test to check readyState directly when onload fires. This is an instance of a more general problem that changes in state of the media element trigger asynchronous events, so the timing of the event firing is dissociated from the observable state change if you query the element. For example, it's possible to receive canplaythrough and the event handler observe that the readyState is not HAVE_ENOUGH_DATA. We discussed this internally but we really need to raise it with the WHATWG list.
This should fix it, it seems to for me.
Attachment #371986 - Flags: review?(chris.double)
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [orange] → [orange][needs 191 landing]
11 years ago
Attachment #371986 - Flags: approval1.9.1+
Target Milestone: --- → mozilla1.9.2a1
Whiteboard: [orange][needs 191 landing] → [orange]
You need to log in before you can comment on or make changes to this bug.