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

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

--- Comment #8 from Philip Jägenstedt <philipj@opera.com> 2011-03-10 16:38:21 UTC ---
(In reply to comment #7)
>   Programming with media is hard, shrug, but I don't think pretending otherwise
> will help. There is no way to paper over the fact that state *does* change
> asynchronously so we should help developers understand this and deal with it. 
> 
>   An extreme example is that of a video which is playing when a modal dialog is
> shown, playback continues and events are queued but not delivered. Scripts that
> run when the dialog is dismissed will see the state of the movie at the time
> the dialog was shown - how can this be helpful?

It's not meant to be helpful or solve a particular use case, the suggested
change is to eliminate some race conditions to make scripting against <video> a
bit more reliable. That doesn't really change things substantially from where
we are today, as the state as seen from scripts can already become out of sync
with reality the instance after it is checked.

To turn it around, how could it be helpful for scripts see the state change
while they are running?

The fact that we have events for all interesting readyState transitions makes
readyState rather uninteresting for scripts, what I hope to avoid is accidental
dependency on de-facto implementation behavior for scripts that *do* check
readyState or do things that indirectly check it, notably setting currentTime
in the loadstart event handler.

> > In short, if not all properties are frozen, they can become internally
> > inconsistent as seen from scripts. Freezing one property would require freezing
> > them all instantaneously, or they could stil become inconsistent. Freezing all
> > of them means always calculating the buffered array even though it may not be
> > used, which is a bit wasteful.
> > 
>   Do you propose to "freeze" the currentTime property too? This will lead to
> very strange behavior when the time jumps around relative to the wall clock,
> eg. it will be pinned when an event is pending and will instantaneously catch
> up the once the last event is posted. Imagine a plot of the delta between the
> wall clock and currentTime during normal playback.

As I understand, Firefox already does this. I don't have a strong opinion about
it, but there's certainly something to be said for internal consistency and
freezing also currentTime. The accuracy of currentTime would be unchanged at
the beginning of an event handler, so I'm not sure it matter that it would
become a bigger and bigger lie the longer the script runs. Is there a use case
for observing changes in currentTime while scripts are running?

-- 
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 Thursday, 10 March 2011 16:38:25 UTC