Bug 12982 - <video> canplay and canplaythrough should only fire once, when the new readyState is HAVE_FUTURE_DATA and HAVE_ENOUGH_DATA for the first time, respectively.
Summary: <video> canplay and canplaythrough should only fire once, when the new readyS...
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Depends on:
Reported: 2011-06-17 21:03 UTC by contributor
Modified: 2011-08-04 05:14 UTC (History)
8 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description contributor 2011-06-17 21:03:45 UTC
Specification: http://www.whatwg.org/specs/web-apps/current-work/complete/the-iframe-element.html
Section: http://www.whatwg.org/specs/web-apps/current-work/#impl

<video> canplay and canplaythrough should only fire once, when the new
readyState is HAVE_FUTURE_DATA and HAVE_ENOUGH_DATA for the first time,

Posted from:
User agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.794.0 Safari/535.1
Comment 1 Rick Waldron 2011-06-17 21:12:46 UTC
The reasoning behind this change is that in its current state, seeking would
cause "canplaythrough" to fire repeatedly.
Comment 3 Rick Waldron 2011-06-17 21:32:03 UTC
Derived from here: https://bugzilla.mozilla.org/show_bug.cgi?id=664842#c0

If an event handler is attached to the "canplaythrough" event ( to take
advantage of HAVE_ENOUGH_DATA state) in which the handler contains logic that
will change thee currentTime, the "canplaythrough" event will be fired again.
At this point the media element will become locked up as the event and handler
enter an infinite feedback loop.


var vid = document.getElementById("video");

vid.addEventListener( "canplaythrough", function() {
  // This line causes it:
  vid.currentTime = 3;

}, false );

Live demo here: http://jsfiddle.net/rwaldron/42r3u/6/

This can only be reproduced in Firefox 4+ as this is the only browser that
implements the spec correctly.
Comment 4 Matthew Gregan [:kinetik] 2011-06-17 22:18:58 UTC
Firefox interprets the spec as allowing canplay/canplaythrough to be fired multiple times as readyState changes allow.  This interpretation is useful because canplaythrough is fired optimistically based on estimated transfer completion time.  This estimate may become invalid if, for example, network conditions or the bitrate of the media changes.  It is useful to signal this change in state by moving to and from HAVE_ENOUGH_DATA (and firing the related events) as conditions change.

Seeking to a new location in the media may result in a previous canplaythrough estimate becoming invalid if the seek location is in an unbuffered segment of the media that requires a new network request to transfer or significant decoding work.  It then becomes more consistent (and therefore easier to code against) if these events are also fired when seeking to a range that is already buffered.

The example code in comment 3 is nonsensical in my opinion and therefore does not provide a valid reason to change the spec.
Comment 5 Ian 'Hixie' Hickson 2011-06-17 22:20:01 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:

Status: Rejected
Change Description: no spec change
Rationale: see comment 4
Comment 6 Michael[tm] Smith 2011-08-04 05:14:51 UTC
mass-move component to LC1