Bug 32141 – HTML 5 Audio "load" event is never fired under Snow Leopard / QuickTime X

• Status: RESOLVED
• Resolution: WONTFIX
• Component: Media

[Joseph Huckaby]

When loading an HTML 5 Audio object and attaching event listeners, the "load" event is never fired.  This event is fired properly under 10.5 with QuickTime 7 (same version of Safari), but is not fired under 10.6 and QuickTime X.

Reproduced on production Safari 4.0.4 (6531.21.10) and the webkit nightly for December 2 (r51580).

Reference Documentation:
http://developer.apple.com/safari/library/documentation/AppleApplications/Reference/SafariJSRef/HTMLMediaElement/HTMLMediaElement.html

Test Page:
http://bowser.macminicolo.net/~jhuckaby/bugs/snow-leopard-audio-load/

[Mark Rowe (bdash)]

<rdar://problem/7443734>

[Joseph Huckaby]

I discovered more information about this bug.  Very, very short MP3 files (less than 0.03 seconds in length) actually fire the "load" event properly.  Any MP3 longer than that will not fire the load event.

Here is another test page which loads MP3s of several different lengths to illustrate:
http://bowser.macminicolo.net/~jhuckaby/bugs/snow-leopard-audio-short/

This test page was created for Bug #32159, regarding MP3s of length 0.03 to 0.10 seconds not loading at all, and generating errors (which you can see on the page), but I noticed the "load" event was actually firing on sounds shorter than 0.03, so added this comment in case you wanted to know.

[Eric Carlson]

The HTML5 spec has been changed and the media element is not supposed to fire the load event at all, although webkit has been updated for this spec change yet.

[Joseph Huckaby]

Thanks Eric.  Quick question: If there is no more "load" event (and no more "progress" event), how can I determine when a sound is completely loaded?  Is there some sort of replacement or equivalent event in the new HTML5 spec?

[Eric Carlson]

> If there is no more "load" event (and no more "progress" event), 
> how can I determine when a sound is completely loaded

You can't tell if a sound or video file is completely loaded, but the 'load' and 'loadend' events were unreliable even when they were in the spec because the UA was only supposed to fire them once "Network connectivity could be lost without  
affecting the media playback", and neither WebKit nor Firefox could actually guarantee that portions of a cached media file would never be evicted from the disk cache. The thread that lead to removing the events and states from the spec, http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-October/023371.html,  has a good discussion of the issues involved.

Your test cases are all small files actually *are* likely to stay in the cache once they are loaded, but we need to make make sure the API works for files of arbitrary size.

[Joseph Huckaby]

Thanks, I understand the reasoning behind it now.  Tis quite unfortunate in the use case of a web game, however.  I need to load 50+ sound effects of various lengths, and have to know when they're all "loaded", so I can start the game engine (so the sounds can all play "instantly" without any latency or network activity).

As a workaround I am listening for the "canplaythrough" event (I hope you guys don't remove that one also, haha).

Thanks for your time on this bug.