486556 - random orange in test_delay_load.html

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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)

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1238659927.1238673627.6525.gz

Comment 3

[Markus Stange [:mstange]]

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1239105199.1239111296.29684.gz

Comment 4

[Jeff Muizelaar [:jrmuizel]]

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1239120821.1239128429.27838.gz

Comment 5

[Serge Gautherie (:sgautherie)]

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1239180376.1239186312.26222.gz
Linux mozilla-central unit test on 2009/04/08 01:46:16

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1239216044.1239225107.9145.gz
(Linux mozilla-central)

Comment 7

[Robert Strong (they/them - no direct email)]

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1239293753.1239299908.17826.gz
Linux mozilla-central unit test

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I can reproduce this in my Linux opt build. Yay!

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

This should fix it, it seems to for me.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http://hg.mozilla.org/mozilla-central/rev/370798d494f8

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 371986 [details] [diff] [review]
fix

Test-only...

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/6d12840bf513