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

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

From: Philip Jägenstedt <philipj@opera.com>
Date: Mon, 6 Jul 2015 13:17:28 +0200
Message-ID: <CAMQvoCm9Ru-w+4x_-Pu_0ekB200CnRnrj7ygVME1vS0UaXXzbg@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: WHATWG <whatwg@whatwg.org>, Andrew Scherkus <scherkus@chromium.org>
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? Since Chrome's
default preload 'auto', I wouldn't expect a whole lot of dependency on
the precise amount of buffering for 'metadata', but would quite expect
some sites to assume that by default one will HAVE_FUTURE_DATA so that
the canplay event is fired.

As for preload 'metadata' itself, it looks like in Chrome it's driven
by the read requests that come out of the media framework, not so much
an explicit policy to decode only one frame:
https://code.google.com/p/chromium/codesearch#chromium/src/media/blink/buffered_resource_loader.h&l=35

I would be unsurprised if there are other issues hidden here, though,
CC Andrew Scherkus who knows the Chromium-side code of this.

Philip
Received on Monday, 6 July 2015 11:17:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 6 July 2015 11:17:55 UTC