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

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

From: Philip Jägenstedt <philipj@opera.com>
Date: Tue, 14 Apr 2009 17:15:09 +0200
To: Philip Jägenstedt <philipj@opera.com>, public-html@w3.org
Message-ID: <op.usdtzjm1atwj1d@sisko.linkoping.osa>
On Thu, 09 Apr 2009 10:49:33 +0200, Philip Jägenstedt <philipj@opera.com>  

> Simon has suggested [1] and Ian confirmed [2] 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.

Actually, the problem isn't limited to slow networks as I initially  
though. If the resource selection algorithm runs interleaved with the  
parser then you can also get several errors events:

<!-- resource selection algorithm starts -->
<!-- no src, throws error -->
<source src=1 media="print">
<!-- media query doesn't match environment, throws error -->
<source src=2 type="text/html">
<!-- media type not supported, throws error -->
<source src=3>
<!-- this one worked, eventually fires load -->

At least for static markup it would make sense if at most 1 of  
error/abort/load is fired. If an error event can be followed by a  
successful load then it was hardly an error to begin with and shouldn't be  
reported. (With scripts you could get as many error/abort/load events as  
you like, but that would be self-inflicted.)

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

This would have to hook into the parser it seems, setting some flag iff  
the element is inserted by the parser and unsetting it when the element is  
closed. Also, begin step 7 by waiting for the parser to close the element  
or for another source element. The rest is details.

Philip Jägenstedt
Opera Software
Received on Tuesday, 14 April 2009 15:14:54 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:44 UTC