[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 #3 from Philip Jägenstedt <philipj@opera.com> 2011-03-08 20:11:12 UTC ---
(In reply to comment #2)
> There seem to be two problems here:
> (a) a script handling an event may be reacting to an 'old' state and

I don't consider this a problem, but if it were then making the suggested
change would make things worse, as the event handler couldn't inspect
readyState/networkState to learn the "real" state.

> (b) when
> testing, it's hard to verify behavior if it's time-dependent and not
> predictable.

Correct. More importantly, it's very easy to write code that is subject to race
conditions if one is not very aware of the issues (and virtual no one except
those who have implemented/done QA on the spec is).

> We can't freeze the video while we process events; I assume that's not what is
> discussed here, but obviously actually pausing is not an option.

That's not what's being suggested, no.

> We could 'snapshot' the state as it was at the time of an event, but that just
> moves the problem down into the engine. That is, we've told the event/scripting
> layer a lie about the true current state, and so when it says "given that the
> state is X I want Y to happen" the state is no longer actually X, so should Y
> happen or not?

This is already the case today, isn't it? When for example the loadstart event
handler runs, it could be that readyState is already HAVE_FUTURE_DATA and
videoWidth and videoHeight are known. However, this is a race condition, so
sometimes it will be true and sometimes not.

Do you have any examples of state X and action Y which could be problematic?

> On testing, it may be that we can introduce some testing hooks to alleviate
> this problem, but I am not sure what they are. I don't think we should distort
> normal operation in order to make it testable, however.

IMO testing is the smaller issue here, the biggest problem is that web authors
can easily write code that breaks randomly depending on network speed, how fast
the decoding pipe line is set up, etc.

-- 
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, 8 March 2011 20:11:14 UTC