W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2015

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

From: Robert O'Callahan <robert@ocallahan.org>
Date: Tue, 7 Jul 2015 14:48:52 +1200
Message-ID: <CAOp6jLZhO=ouyccMrAH4Fb_7z4+M+=uh7V9oHVkC=6E5yUJdJw@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: WHATWG <whatwg@whatwg.org>, Andrew Scherkus <scherkus@chromium.org>
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
> >> > 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

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

lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
Received on Tuesday, 7 July 2015 02:49:20 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:33 UTC