On Tue, Jul 7, 2015 at 1:44 AM, Philip Jägenstedt <phil...@opera.com> wrote:
> On Mon, Jul 6, 2015 at 2:19 PM, Robert O'Callahan <rob...@ocallahan.org> > wrote: > > > On Mon, Jul 6, 2015 at 11:17 PM, Philip Jägenstedt <phil...@opera.com> > > wrote: > > > >> On Wed, Jun 10, 2015 at 6:53 AM, Robert O'Callahan < > rob...@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
