This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 12595 - <video> Fire suspend event when/if entire resource is loaded
Summary: <video> Fire suspend event when/if entire resource is loaded
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
Depends on:
Blocks: 12289 12608
  Show dependency treegraph
Reported: 2011-05-04 11:50 UTC by contributor
Modified: 2011-09-08 21:23 UTC (History)
8 users (show)

See Also:


Description contributor 2011-05-04 11:50:58 UTC

Fire suspend event when/if entire resource is loaded

Posted from:
User agent: Opera/9.80 (X11; Linux x86_64; U; en) Presto/2.8.131 Version/11.10
Comment 1 Philip Jägenstedt 2011-05-04 12:01:18 UTC
As part of the work to bring sanity to the event order in video loading combined with preload (, I changed Opera to always fire the suspend event when transitioning to networkState=NETWORK_IDLE. This is not in line with the spec, which only allows firing the suspend event when a UA decides to not download more content, and supposedly reaching the end of the resource is not a decision.

I suggest that in addition to a UA being conservative with bandwidth and suspending an ongoing load, the suspend event should also fire if the the UA should ever buffer up to the end of the resource.

Firefox already does this and Opera is going to. Chromium seems buggy, actually firing the suspend event whenever one begins to play (!).
Comment 2 Philip Jägenstedt 2011-05-04 12:07:33 UTC
Filed this bug on Chromium:
Comment 3 Philip Jägenstedt 2011-05-04 12:11:13 UTC
Some rationale for the change as well:

1. It's easier to implement if one fires the suspend event when the network stops being active, regardless of the reason. Specifically, it's annoying to have to special-case the situation when the last HTTP request (using Range header) happened to be the last piece to have the whole resource.

2. If one supports throwing away part of the cache, then having loaded all of the resource would in a sense just be suspending, because one might later have to resume buffering of evicted parts.

3. For page authors, it seems simpler to have a single event that always means that the network is no longer active. For example, a small indicated (glowing red sphere or some such) to indicate network activity would be easier to toggle on/off. The alternative is checking networkState in the progress event handler.
Comment 4 Philip Jägenstedt 2011-05-04 12:15:03 UTC
To be clear, what Opera does is to fire the suspend event when going to NETWORK_IDLE, regardless of the reason. If the reason was a network error or abort, I'm not convinced this is a good idea, so this might change. We'll probably align with whatever the spec says on this eventually.
Comment 5 Ian 'Hixie' Hickson 2011-08-02 22:55:38 UTC
The idea of the 'suspend' event is to indicate that the user agent has stopped trying to get the resource; as contrasted to 'stalled' which is to indicate that the network has stopped providing the resource, despite the user agent's desire to get it.

Firing either of these when the resource is completely loaded doesn't really make sense. In fact, firing _anything_ when the resource is completely loaded is a bit dodgy, because it might lead to authors triggering things based on when the resource is completely loaded.
Comment 6 Philip Jägenstedt 2011-08-03 08:51:25 UTC
OK, so the title of this bug was poorly chosen.

What I am saying is that when the transfer has stopped in an expected manner (networkState=IDLE), the suspend event should be fired. As currently spec'd, if the resource does not fit in cache the transfer will have to be suspended and a suspend event fired, while if it does no suspend event will be fired. It seems better to always fire a suspend event, as otherwise it will only happen in disk-limited situations which authors are far less likely to test with.
Comment 7 Michael[tm] Smith 2011-08-04 05:06:35 UTC
mass-moved component to LC1
Comment 8 Ian 'Hixie' Hickson 2011-08-17 18:04:19 UTC
I think if we fire 'suspend' at the end, what's more likely to happen is that instead of just ignoring the event and having the element still mostly work, authors will wait for 'suspend' and treat it like 'onload', not starting to use the resource until it happens, and when it does, assuming the whole thing is cached. So for example they would load a sound effects file, wait for 'suspend', and then once it fires start playing back clips from anywhere in the file expecting zero latency.

Why is this not worse?
Comment 9 Philip Jägenstedt 2011-08-18 09:08:10 UTC
If they do that, they'll still get as good an experience as is possible given the cache size. What harm could come of it, except that the latency won't be as low as on a device with infinite bandwidth and cache?
Comment 10 Ian 'Hixie' Hickson 2011-09-08 20:24:40 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:

Status: Accepted
Change Description: see diff given below
Rationale: Fair enough.
Comment 11 Ian 'Hixie' Hickson 2011-09-08 21:23:17 UTC
Checked in as WHATWG revision r6544.
Check-in comment: Make 'suspend' fire when the media is loaded.