The resource selection algorithm queues a task to fire 'loadstart' (and subsequent events are also queued). However, readyState transitions are immediate and take effect immediately. So if a video is cached or is loaded locally, you could get to HAVE_ENOUGH_DATA before 'loadstart' is fired, which means that the video is autoplayed before a script has had a chance to remove the autoplay attribute.

To fix this I suggest that the readyState transition to HAVE_ENOUGH_DATA should say something like:

If the autoplaying flag is true, and the paused attribute is true, then queue a task to run the following steps:
1. If the media element has an autoplay attribute specified, and the media element's Document's browsing context did not have the sandboxed automatic features browsing context flag set when the Document was created, then the user agent may also set the paused attribute to false, fire a simple event named play, and fire a simple event named playing.

(I have not pondered about what effect this has on the sandboxed automatic features stuff.)

If you don't want it to autoplay, why would you set autoplay? I don't understand the use case for worrying about this.

(In reply to comment #2)
> If you don't want it to autoplay, why would you set autoplay? I don't
> understand the use case for worrying about this.

This problem was found when someone was trying to develop an extension to stop media elements from autoplaying.

Another example of event raciness that I just stumbled upon:

We had a test for checking the order of events in for preload=metadata. In the loadstart event handler, event handler for 'progress', 'suspend', 'abort', 'error', 'loadedmetadata', 'loadeddata', 'canplay', and 'canplaythrough' were registered, but it depends on chance which of these have already been fired. In our case, we missed the first progress event, but got the rest.

Of course it's possible to write code to avoid the race conditions, but if we as browser developers accidentally do things like this, then we can be 100% sure that web authors will also inadvertently come to depend on the most common outcome of race conditions in common browsers.

> This problem was found when someone was trying to develop an extension to stop
> media elements from autoplaying.

That's something that should be done natively by the UA.

If an extension is actually going to do this, it should be done from mutation events (or their brethren), long before 'loadstart' fires.

We can't do what comment 1 suggests since that would block autoplay behaviour if there was another task running (e.g. with an alert()).

Comment 4 seems to be a separate issue. That issue is present across the Web platform, it's not unique to <video>. We can't gate the processing of video on whether JS has handled the previous step, that would just kill performance in any case where there was a high load.


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:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: see aboe

This and what I mentioned in comment 4 would be fixed by http://www.w3.org/Bugs/Public/show_bug.cgi?id=12267 so let's take the discussion there.

mass-moved component to LC1