[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 #40 from Robert O'Callahan (Mozilla) <roc@ocallahan.org> 2011-08-01 00:00:20 UTC ---
(In reply to comment #39)
> 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.

I claim that we can actually reduce the set of weird behaviors. The weird
behaviors with my proposal that you've raised so far can all happen with the
current spec and other browser implementations as well.

> 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.

I don't understand why you say that a value that's X > 0 microseconds stale is
a "lie" but a value that's Y > 0 microseconds stale is not, just because X
happens to be greater than Y sometimes. They're either both lies or they both
aren't.

Debugging is not going to affected if you only use logging and your event
handlers don't take long to run. If you pause a running script in the debugger
and then repeatedly inspect media element state in the debugger, perhaps by
calling DOM APIs, then the author might be confused by those APIs not
reflecting what's on the screen, I agree. On the other hand, breakpoints and
single-step debugging are often quite useless for finding and fixing bugs in
code dealing with asynchronous state changes; a more snapshotting approach can
actually *aid* breakpoint-based debugging because if you hit a breakpoint,
execution will continue after the breakpoint the same as if you hadn't stopped
in the breakpoint. Changing behavior when you add breakpoints sucks! Also, I
believe reducing the incidence of very hard-to-reproduce bugs would more than
compensate for any confusion here.

> 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?

Yes.

> Should doing something like calling load() reset the
> state somehow?

Yes.

> If the script calls pause(), should currentTime get updated to
> the actual time it was paused at?

That sounds like a good idea although I don't think it's absolutely necessary.

> 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.

Fair enough. I don't know when I'll have time to come up with that :-(.

> (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.

Sorry, I misread your original mention of pauseOnExit. I agree that when adding
a cue, the best behavior would be to simply ignore the cue if the true current
time has already advanced past the end of the cue. My general suggestion would
be to make a task's MutableTextTrack changes all take effect atomically after
the task has completed.

-- 
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 00:00:28 UTC