W3C home > Mailing lists > Public > public-html@w3.org > April 2009

Media elements may never load, may load the wrong source, etc

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 29 Apr 2009 19:14:14 +0000 (UTC)
To: Philip Jägenstedt <philipj@opera.com>, Simon Pieters <simonp@opera.com>
Cc: public-html <public-html@w3.org>
Message-ID: <Pine.LNX.4.62.0904290850050.10370@hixie.dreamhostps.com>
On Thu, 9 Apr 2009, Philip Jägenstedt wrote:
> I think it's necessary to add a clause after step 1.4 that the script 
> which modified src/source must complete before the (now asynchronous) 
> resource selection algorithm continues. Otherwise, a script like...
> a=new Audio();
> a.src="audio.ogg";
> <!-- async algorithm could set NETWORK_LOADING and run step 3-4 -->
> if (condition)
>   a.src+="?t=0:00:10/0:00:20";
> else
>   a.src+="?t=0:00:20/0:00:30";
> ...might cause "audio.ogg" to be loaded even though it wasn't even a 
> candidate. It's a race condition, but even for more trivial cases 
> allowing the script to first finish modifying the DOM must give a more 
> predictable behavior.

I agree that we want predictable behaviour. I've added predictable 
behaviour, but in the example above the first src="" value is the one that 
is used, not the one after it is changed. Each change of src="" requires a 
new invokation of load().

The same kind of thing can happen if a <source> is inserted then removed. 
While preventing any kind of weirdness here is nigh on impossible (if 
someone adds then removes then changes the attributes, keeping track of 
which src="" we're supposed to load would be a nightmare), I have at least 
made it so that the browser will wait til any scripts have stopped 
fiddling before trying to apply the next <source> element.

> Simon has suggested and Ian confirmed that
>    <video>
>     <source src=1>
>     <source src=2>
>     ...
>     <source src=n>
> Can generate n-1 error events with error code MEDIA_ERR_NONE_SUPPORTED on a
> slow network.
> This seems like a very bad behavior as authors are likely to use this error to
> determine if they need to replace the element with fallback content. The slow
> network issue is likely to be overlooked and even if the author is aware of it
> it's not trivial to determine if you got the error because of the network or
> because there really was no supported source.
> We first suggested firing one error event for each source that isn't
> supported, adding the URL of the unsupported resource to MediaError object.
> That might be overkill, but there must instead be a guarantee that the event
> only fire once and only if no more <source> tags are going to trickle in over
> the network. It's quite simple to just keep waiting if the <video> tag hasn't
> been closed yet, but I'm not sure how such a requirement can be stated in
> terms of DOM. Ideas?

I've removed the 'error' event from firing on the <video> in the case of 
<source> being used. It just fires on the <source>s. That makes it more 
reliably understandable.

more closely match what it's now used for.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 29 April 2009 19:14:50 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:46 UTC