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

On Wed, 08 Jul 2009 03:16:35 +0200, Ian Hickson <ian@hixie.ch> wrote:

> On Wed, 10 Jun 2009, Philip Jägenstedt wrote:
>> On Sat, 06 Jun 2009 02:56:26 +0200, Ian Hickson <ian@hixie.ch> wrote:
>> > On Wed, 6 May 2009, Philip Jägenstedt wrote:
>> > > 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.
>> >
>> > The problem is that the behaviour with <source> is highly volatile. We
>> > can't remove this volatility for <source> easily, but we _can_ remove
>> > it for src="".
>> >
>> > If we don't use the first value for src="", then we end up in a weird
>> > position where you can't predict which value of src="" will be used
>> > if, e.g., there is a setInterval() script running that keeps changing
>> > it, because the tasks scheduled by the setInterval() script and the
>> > tasks scheduled by the resource selection algorithm are from different
>> > task sources and thus don't have a defined order.
>>
>> This is not a problem in actual implementation as the async part is
>> simply run once the script triggering the resource selection algorithm
>> has finished. Other implementations are possible *per spec*, but it
>> would be asking for cross-browser compatibility bugs to wait any longer
>> as it would cause the same unpredictable behavior with <source> elements
>> (if a playable <source> element is added and later removed in a
>> timeout).
>
> Yes, the problem you describe exists with <source>. I don't know how to
> avoid it. I wish we could. I don't think introducing the same problem for
> src="" is a good design, though.
>
> If we want something else, then we should spec it exactly -- that is, if
> you think the implementations are constrained more than the spec allows,
> then that's what the spec should say.

I'd be surprised if any other implementations have race conditions for  
<source> elements either. I'd prefer wording requiring the resource  
selection algorithm to continue the "asynchronous" steps once the  
triggering script has finished, similar to the old wording for the  
implicit load(): "the user agent must implicitly invoke the load() method  
on the media element as soon as all other scripts have finished  
executing". There's no element of chance involved as far as I can see. If  
this could help remove the different handling of src/source with two  
different waiting states and ugliness, all the better.

>> > What should we do if someone, in one task, sets the src="", then
>> > removes it, then inserts a <source>, then removes it?
>>
>> Since we also suggest getting rid of NETWORK_NO_SOURCE, the whole
>> resource selection algorithm would be slightly different, something
>> like:
>>
>> 1. While the media element has neither a src attribute nor any source
>> element children, wait.
>>
>> 2. Before the task that set the src attribute or inserted the source
>> element has a chance to complete, set the media element's
>> delaying-the-load-event flag to true (this delays the load event), and
>> set its networkState to NETWORK_LOADING. Wait for the task that set the
>> src attribute or inserted the source element to complete.
>>
>> It then continues approximately the same from there, except that the the
>> later waiting steps return to step 1. In this way, adding/removing
>> @src/<source> has the net effect of nothing and maybe an error event.
>>
>> At least I would prefer this rather simpler algorithm where
>> @src/<source> are treated equally for the most part. In terms of
>> understanding and implementating the algorithm it is simple. If the spec
>> has trouble defining such behavior then I would regard that as a spec
>> problem primarily.
>
> So basically you're saying that we should have some mechanism to hook  
> into
> the event loop and run some a task as soon as the current task has ended,
> but before the next task runs?
>
> I guess I could do that. I'm very reluctant to make the event loop
> mechanism even more complex, though.

Yes, I'm saying that's what you'd actually do in an actual implementation,  
anything else is just asking for unpredictable behavior. As I'm sure  
you're aware most (all?) browser don't update the layout until scripts  
modifying the DOM have finished, I think this is really a similar case.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Wednesday, 8 July 2009 08:49:36 UTC