W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > April 2011

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

From: <bugzilla@jessica.w3.org>
Date: Wed, 20 Apr 2011 16:15:04 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QCa3U-0002Sp-O9@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12267

--- Comment #14 from Philip Jägenstedt <philipj@opera.com> 2011-04-20 16:15:03 UTC ---
(In reply to comment #13)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > Freezing is not appropriate, as we all recognize; and snapshot means that
> > > scripts are using state/values that are old, and then asking for action based
> > > on that. is currentTime one of the snapshotted values?  If so, is timeofday
> > > also snapshotted, so we can see how well we are playing in real-time? And so
> > > on...
> > 
> > The best behavior of currentTime isn't obvious, I'll agree thus far. Are there
> > any use cases for scripts observing currentTime changes while they are running?
> 
> A script that displays captions, subtitles, slides, etc, in sync with a playing
> video? Keeping relatively accurate sync is hard enough, why make it worse?

Such scripts would have to "yield" by returning from their setTimeout or event
handler to have any visible side-effects. You can't have a never-returning
script observing changes in currentTime that doing anything useful, really.
(AFAIK, only Opera actually has an interruptible script engine, so in any
browser it would just be a broken script.)

Sure, if a script runs for a very long time before checking currentTime, then
there would be sync issues. However, a browser could choose to freeze the
HTMLMediaElement state when it is first accessed in each task, so I doubt it
would be a practical problem. Also, with the addCue API, authors will be able
to depend on the browser for timing instead.

> > If not, what concrete problems would freezing it (like Firefox, presumably)
> > cause?
> 
> What concrete problems would freezing currentTime solve?

It guarantees consistency between all the different states as observed by
scripts. That makes writing test cases more reliable, but more importantly I
assume we will see pages accidentally breaking because of this sort of thing if
we allow things to be "random".

If we *don't* freeze currentTime, then the spec should really define what it is
scripts would observe by repeatedly reading the property. How often should it
be updated, at a minimum?

I'm not in love with the idea of giving myself more work by coercing the
script-visible state in all kinds of ways, but the alternative seems worse,
after all.

-- 
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 Wednesday, 20 April 2011 16:15:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:08 UTC