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

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12267

           Summary: Make video state transitions happen in the same task
                    as firing events
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: simonp@opera.com
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


A major hurdle with the video spec is that state transitions
(readyState/networkState) happen sync (and even while script is running, except
in Firefox which keeps a snapshot of the states, which is better but still not
perfect) while events are put on the event queue (i.e. get fired later). The
WebSocket API spec OTOH keeps state transitions and events in sync by putting
both on the event queue as a single task, e.g.

"When the WebSocket connection is established, the user agent must queue a task
to first change the readyState attribute's value to OPEN (1); apply the cookies
that were collected in the list of cookies when the connection was established;
change the protocol attribute's value to the selected WebSocket subprotocol, if
there is one; and then fire a simple event named open at the WebSocket object."
http://www.whatwg.org/specs/web-apps/current-work/complete/network.html#feedback-from-the-protocol

That example applies cookies etc as well in the same task.

The video spec should be overhauled so that state transitions and events happen
at the same time, so that things are predictable, testable and easier to author
against.

If we do this, we also need to freeze *all* state to keep things in sync. If
other properties are still allowed to change while the script is running,
weirdness ensues:

* ended == false even though readyState is still in HAVE_ENOUGH_DATA

* currentTime == duration even though readyState is still in HAVE_ENOUGH_DATA

* currentTime could increase beyond 0 while readyState is still HAVE_METADATA

* the two above three issues but observed though played

* buffered is changing even though networkState is NETWORK_IDLE

In short, if not all properties are frozen, they can become internally
inconsistent as seen from scripts. Freezing one property would require freezing
them all instantaneously, or they could stil become inconsistent. Freezing all
of them means always calculating the buffered array even though it may not be
used, which is a bit wasteful.

Overall, though, I think that we should move in the direction of freezing the
properties for scripts, as what we have now is so full of race conditions it's
not even funny.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Tuesday, 8 March 2011 15:46:10 UTC