The reasoning behind this change is that in its current state, seeking would
cause "canplaythrough" to fire repeatedly.

Also see
https://bugzilla.mozilla.org/show_bug.cgi?id=664842
http://krijnhoetmer.nl/irc-logs/whatwg/20110617#l-1304

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.

eg.

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.

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.

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:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: see comment 4

mass-move component to LC1