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

On Tue, Jul 7, 2015 at 4:48 AM, Robert O'Callahan <robert@ocallahan.org>
wrote:

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

Unsurprisingly, I like this, as it's basically what Presto did. However, I
think preload="metadata" should reach HAVE_CURRENT_DATA, because you do
want to decode the first frame. The naming mismatch is weird, but oh well.


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

Do you have links to previous debacles, so that I can see what the
constraints are, or have been? Given that Blink's default preload state is
auto that ought to limit the breakage somewhat, but I wouldn't really be
surprised to find sites that use preload="metadata" and yet assume that
canplay will fire, or similar.

Whatever kind of mess we're in, it would be nice to aim for
interoperability.

Philip

Received on Tuesday, 7 July 2015 09:42:18 UTC