Re: [whatwg] preload="metadata" elements don't necessarily fire "canplay"

On Tue, Jul 7, 2015 at 1:44 AM, Philip Jägenstedt <philipj@opera.com> wrote:

> On Mon, Jul 6, 2015 at 2:19 PM, Robert O'Callahan <robert@ocallahan.org>
> wrote:
>
> > On Mon, Jul 6, 2015 at 11:17 PM, Philip Jägenstedt <philipj@opera.com>
> > wrote:
> >
> >> On Wed, Jun 10, 2015 at 6:53 AM, Robert O'Callahan <
> robert@ocallahan.org>
> >> wrote:
> >> > In Gecko, <video preload="metadata"> doesn't fire "canplay". This is
> >> > allowed (encouraged, even) by the spec, since we can efficiently
> satisfy
> >> > preload="metadata" by stopping decoding after one frame, and if we
> only
> >> > decode one frame then readyState will not advance beyond
> >> HAVE_CURRENT_DATA.
> >> > However, this may be counterintuitive for Web developers. Also, Chrome
> >> > fires "canplay" in this situation (although that's probably part of
> the
> >> > "Chrome fires canplay and canplaythrough willy-nilly" bug). Anyone
> else
> >> > have an opinion on this?
> >>
> >> Are you having site compat problems related to this?
> >
> > There's https://bugzilla.mozilla.org/show_bug.cgi?id=1165203 (the same
> > bug as in the other thread), thought that involves load() as well. I
> don't
> > know of any sites where this causes problems in the absence of load(),
> > though I wouldn't be surprised if they exist. I think it would be a good
> > idea to align browser behaviors or the spec.
>
> Yeah, I agree. In Presto I added some explicit limits to readyState based
> on preload so that even for data: URLs or fully cached resources, it
> wouldn't progress beyond HAVE_CURRENT_DATA. (However, buffered wasn't
> censored, so it could look a bit strange if inspected closely.) Is this how
> it works in Gecko too, or is it actually the media framework that makes the
> guarantee without any clamping on top of it?
>

We don't do any clamping of the state, so given preload="metadata" you may
or may not reach HAVE_CURRENT_DATA or HAVE_FUTURE_DATA (or even
HAVE_ENOUGH_DATA).

My previous attempts to nail down the precise behavior or preload haven't
> gone well, as Hixie considers preload as a hint where anything goes. Even
> so, specifying the "normal" behavior seems like a good idea.
>
> In the specific case of preload="metadata", what would you like the spec to
> say?
>

Clamping the readyState would be a good way to get reliable behavior and
interop while keeping preload useful. We'd spec some kind of "goal
readyState" associated with a resource load, and spec that readyState is
clamped to the goal readyState. For preload="none" that's HAVE_NOTHING, for
preload="metadata" that's HAVE_METADATA, for other preload values it would
be HAVE_ENOUGH_DATA. Method calls like play() or setting autoplay would
force it to HAVE_ENOUGH_DATA and it could never decrease.

The question is, would Chrome(ium) be willing to implement that reasonably
quickly? I'm not optimistic given the canplaythrough debacle...

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn

Received on Tuesday, 7 July 2015 02:49:20 UTC