664842 - Setting currentTime causes canplaythrough to fire forever

Status: RESOLVED INVALID

(Core :: Audio/Video, defect)

Description

[David Humphrey (:humph)]

We noticed an issue today while fixing something in popcorn.js.  If you set currentTime early, it causes canplaythrough to fire forever, and makes the video unusable.

var vid = document.getElementById("video");
var log = document.getElementById("log");
vid.addEventListener( "canplaythrough", function() {
  // This line causes it:
  vid.currentTime = 3;
  log.innerHTML += " canplaythrough ";
}, false );

Live demo here: http://jsfiddle.net/42r3u/2/

Chrome only fires canplaythrough once no matter what we do with currentTime.  My reading of the spec would leave me to believe that this is the correct behaviour.

Comment 1

[Chris Pearce [:cpearce (Not reading bugmail)]]

The spec here:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#event-media-canplaythrough

Says: canplaythrough fires when "readyState is newly equal to HAVE_ENOUGH_DATA.".

Elsewhere it says "When the ready state of a media element whose networkState is not NETWORK_EMPTY changes, the user agent must follow the steps given below: [...] If the new ready state is HAVE_ENOUGH_DATA [...] the user agent must finally queue a task to fire a simple event named canplaythrough."

When we seek we switch to readyState HAVE_CURRENT_DATA (there was talk on the WhatWG mailing list that we should actually switch to HAVE_METADATA while seeking, but we've not implemented that yet) so when we exit seeking and start downloading/playing data again, we'll eventually reach HAVE_ENOUGH_DATA and thus fire "canplaythrough".

I think our behaviour is spec compliant, and I know that Chrome's implementation of canplaythrough is broken; they fire canplaythrough as soon as they load the first frame, and then never again. We've filed a bug about this at http://code.google.com/p/chromium/issues/detail?id=73609

Comment 2

[Rick Waldron [:rwaldron]]

Like David, I've also been interpreting both the WhatWG and w3c video element specs to imply that the "canplaythrough" event should only ever be fired once. Incidentally, Silvia Pfeiffer's book, "The Definitive Guide to HTML5 Video" claims that it should only be fired the _first_ _time_ HAVE_ENOUGH_DATA is fired... it also appears that this text might quoting an old version of the spec.

My guess is that Chrome implemented against the production described in this older spec. 

http://www.w3.org/2010/05/video/mediaevents.html

This test suite can be used to reproduce the behaviour outside of using currentTime

Comment 3

[David Humphrey (:humph)]

Chris, 

There are at least 2 things here.  First, the issue as to whether or not canplaythrough should fire more than once (I'm still convinced multiple events makes little sense, but I agree that the text you quoted leaves room for multiple interpretations).  This point notwithstanding, the actual behaviour of doing an early seek is that the video becomes unusable.  It is as though the seek is happening over and over--play is broken, the throbber spins forever, manual seeking doesn't work, etc.

Whatever we do about the first issue, this second issue has to point to a bug.

Comment 4

[David Humphrey (:humph)]

Based on irc discussions, I think our reading of the spec is incorrect, and that due to seeking, canplaythrough will/could fire more than once.  Marking invalid.  That there is so much disparity between vendors on this is a problem, but I'm encouraged to see the Chrome bug you filed above.

Comment 5

[Matthew Gregan [:kinetik]]

Rick is asking for the spec to be changed: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12982