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

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.


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

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'