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

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

From: <bugzilla@jessica.w3.org>
Date: Tue, 26 Jul 2011 17:45:02 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Qllgk-0005Gb-Bb@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12267

Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |12541, 12175

--- Comment #39 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-07-26 17:44:58 UTC ---
I really couldn't disagree more. If we're going to get confusing behaviour
anyway, let's not have both confusing behaviour *and* make the APIs lie all the
time.

I'm fine with making APIs appear stable during script execution if doing so
actually makes the APIs stable. So for instance, it makes perfect sense for
something like XHR to be stable, because the user agent can fake it
convincingly. But with <video> this doesn't work. You're just exchanging one
set of weird behaviour for another set. At least when the APIs reflect reality
there's no difficulty in working out why things are acting as they are. If the
API is lying on top of it, debugging this stuff will become nightmarish, with
the API saying one thing and the browser showing another.


Much of the spec machinery here depends on the variosu states. For example,
what events fires when you call play() depends on whether it's able to play or
not. Are you suggesting that things like that be based on the state when the
script task started? Should doing something like calling load() reset the state
somehow? If the script calls pause(), should currentTime get updated to the
actual time it was paused at?

If I'm to spec this, I need a comprehensive list of what should happen. I can't
work it out myself; every attempt I have made at working out how to do this has
resulted in me concluding that it's a bad idea and that nothing should be
frozen here.


(In reply to comment #36)
> 
> In Gecko, after the cue has been set up, an internal task updates currentTime
> from 5 to 7, and the cue handler would run and pause the media when the real
> playback time is something greater than 7.

IMHO this is a complete failure. The whole point of pauseOnExit is to pause at
exactly the given time. Not pausing makes sense (because the time was missed),
but pausing at the wrong time is inexcusably buggy and breaks the use case
entirely.

-- 
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 Tuesday, 26 July 2011 17:45:07 UTC

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