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

On Wed, 29 Apr 2009 21:14:14 +0200, Ian Hickson <ian@hixie.ch> wrote:

> 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.

This is an improvement in predictability, but implementing it turns out to  
be unnecessarily painful... Manipulating src should pin down the resource  
immediately (resolving the URL, as later we must know the "the absolute  
URL that would have resulted"). Manipulating <source> should however  
effectively wait until the current script has finished before running the  
search loop. It would be much easier if one could always wait with  
checking src/source until the running script has finished. This makes for  
less special cases and less state to remember across the sync/async  
boundary.

A curious side-effect of the current assymetry is that changing xml:base  
or <base> after src="" (even immediately in the same script) should have  
no effect, but the same isn't true of <source> elements. Of course I'm  
biased as I don't want to implement the spec as written, but wouldn't  
consistent behavior here be better?

Unless there's a compelling case for pinning down src on first change, I'd  
strongly prefer if the "let src equal the first value that was assigned"  
part was revoked and that any tasks that could change the outcome of the  
asynchronous part of the algorithm are allowed to complete before step 3  
(i.e. let the current script finish, using whatever terminology).

>> 3. about MEDIA_ERR_NONE_SUPPORTED
>>
>> 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.
>
> I've renamed MEDIA_ERR_NONE_SUPPORTED to MEDIA_ERR_SRC_NOT_SUPPORTED to
> more closely match what it's now used for.
>

OK, this makes sense. This creates some asymmetry in the error/abort/load  
events, but I suppose this is an acceptable trade-off. Listening to the  
error event on both <video> and the last <source> should do the trick.

-- 
Philip Jägenstedt
Opera Software

Received on Wednesday, 6 May 2009 14:49:05 UTC