- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 23 Feb 2009 08:56:16 +0000 (UTC)
On Mon, 9 Feb 2009, Robert O'Callahan wrote: > > I was just writing some tests for various events and noticed that > there's a slight weirdness in the events fired for readyState > transitions. If readyState changes from HAVE_CURRENT_DATA to > HAVE_FUTURE_DATA, the element is then potentially playing, and then > readyState changes to HAVE_ENOUGH_DATA, we fire "canplay", "playing", > "canplay" again, "canplaythrough" and "playing" again. OTOH if > readyState changes from HAVE_CURRENT_DATA directly to HAVE_ENOUGH_DATA > and the element is potentially playing, then we fire "canplay", > "canplaythrough", and "playing". > > I think we should fire the same set of events in the same order whether > we transition through HAVE_FUTURE_DATA or not. So, I suggest that a > transition from HAVE_FUTURE_DATA to HAVE_ENOUGH_DATA should not fire > "canplay" or "playing". Also, a transition from HAVE_CURRENT_DATA to > HAVE_ENOUGH_DATA should fire "canplaythrough" after we've handled > autoplay and potentially fired "playing". I've tried to make this much more consistent. You were definitely right that there were far too many duplicate and out-of-order events before. Please let me know if the new spec is still doing silly things. Thanks, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 23 February 2009 00:56:16 UTC