[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

Robert O'Callahan (Mozilla) <roc@ocallahan.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |

--- Comment #29 from Robert O'Callahan (Mozilla) <roc@ocallahan.org> 2011-06-02 23:11:42 UTC ---
(In reply to comment #28)
> We can't possibly make the API work according to frozen state rather than
> current state, imagine what would happen if there was a task that alert()ed,
> then the video ended, then the script called play()... do you want to have to
> remember that the video was playing, so play() should do nothing, even though
> now the video has finished, so really it should restart?

alert() needs special treatment; for our purposes here, it needs to be treated
as ending the current task and starting a new one, so fresh video state is
available after alert() returns. This is very much like how alert() gets
special treatment to drop the storage mutex etc. Same deal for sync XHR and the
other usual suspects.

Keep in mind that we have implemented most of this in Gecko. We have alert()
etc spin a restricted nested event loop; we update the script-visible media
element state in events that can be processed in such a nested event loop.

I think alert() and its evil siblings don't have to block us from making the
programming model saner here. Please reconsider.

-- 
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, 2 June 2011 23:11:46 UTC