But that’s all it means - it doesn’t mean any data has actually loaded, or that the media resource even exists. The first to fire in all cases is the 'loadstart' event, which means that the browser has begun to look for data. whether the preload attribute is used and/or whether the media is already cached. The prevalence of these events depends on the loading state of the media, i.e. The loading events are those which fire in respect of loading (or failing to load) media data. the button would do nothing at all): button.addEventListener('click', function(e)īut you can fix this quirk quite easily, by firing the pause() method manually in response to the 'ended' event: media.addEventListener('ended', function(e)įirefox and Chrome already fix this internally, and in exactly the same way - by firing a 'pause' event just before the 'ended' event.

A practical upshot of this is that a simple play/pause button handler like this would fail in that situation (i.e. paused flag remains false when the media has ended (yet logically, it should be true since the media is no longer playing). However there is a significant anomaly here in Opera, Safari and IE10, which is that the. at the same time as the 'ended' event fires). ended property is false by default, but then becomes true when playback reaches the end (i.e. paused property is true by default, or whenever the media is paused, while the. There are also two media properties that correspond with the last two events - the. There are media functions that correspond with the first two events - unsurprisingly called play() and pause().

The 'play' and 'pause' events fire when the media is played or paused (respectively), but there’s also an 'ended' event which fires when the media reaches the end - either because ordinary playback has finished, or because the user manually “seeked” that far. The playback events are those which fire in response to playing or pausing the media.

Html5 audio ended