[Bug 12267] <video> Make video state transitions happen in the same task as firing events

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12267

--- Comment #46 from Robert O'Callahan (Mozilla) <roc@ocallahan.org> 2011-08-01 22:40:27 UTC ---
(In reply to comment #45)
> Preventing the video from playing until the events have been processed seems
> like building latency into the design. Event dispatch can sometimes be delayed
> quite a lot, e.g. if there's a lot of activity going on. Are we sure we want to
> be introducing this kind of latency?

I don't think we need to prevent the video from playing. It's only the
script-observable values of readyState/networkState that are not updated until
the relevant events have fired.

> I don't know that readyStates would make sense done this way
> though. There's no point readyState saying there's FUTURE_DATA when the video
> has actually ended.

I think there is. I think it will confuse authors to find that sometimes when
canplay fires, readyState is HAVE_CURRENT_DATA (or in general, that the
preconditions listed in 4.8.10.16 usually hold when the event fires, but
occasionally don't). Setting readyState in the task that dispatches the event
fixes that problem.

Sure, that could mean readyState returns HAVE_FUTURE_DATA when the video has
already ended, but that's effectively possible today when you allow readyState
to change asynchronously and the video ends the moment after readyState was
fetched. E.g.
  if (video.readyState >= video.HAVE_FUTURE_DATA) {
    // video happens to end here
    doSomethingAssumingVideoHasNotEnded();
  }
There is no way to prevent this problem in anyone's model.

> Similarly, it's not like you can actually prevent the video
> from ending before it's ended. The video ends when you run out of material,
> regardless of how busy the browser is.

Sure.

I'll be honest and admit that without having done all the spec work myself, I
can't be 100% sure that the spec can be made to work this way across the board
without creating new problems. I'm pretty sure the general approach of only
updating script-observable state during stable states can work because Firefox
is implemented that way and it's working well, but I'm less sure about this bug
(delaying readyState/networkState updates until the event fires).

For example, I think to make this work we'd have to sometimes cancel events in
response to scripted state changes. E.g. if the readyState is
HAVE_CURRENT_DATA, the video loads some future data, and a task is dispatched
to set readyState to HAVE_FUTURE_DATA and fire the "canplay" event, but some
script does "currentTime = 0;" before that task runs, we will probably want to
prevent readyState from temporarily flipping to HAVE_FUTURE_DATA and back after
the seek, and prevent "canplay" from firing. I hope that can be worked out, but
maybe there are some bad implications.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 1 August 2011 22:40:30 UTC