W3C home > Mailing lists > Public > public-html-media@w3.org > March 2013

[Bug 21374] New: Clarify abort algorithm

From: <bugzilla@jessica.w3.org>
Date: Fri, 22 Mar 2013 10:44:46 +0000
To: public-html-media@w3.org
Message-ID: <bug-21374-5436@http.www.w3.org/Bugs/Public/>

            Bug ID: 21374
           Summary: Clarify abort algorithm
    Classification: Unclassified
           Product: HTML WG
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Media Source Extensions
          Assignee: adrianba@microsoft.com
          Reporter: cyril.concolato@telecom-paristech.fr
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-media@w3.org

It is not to me clear when reading the spec why the abort algorithm behaves
differently with appendBuffer and appendStream, in particular why the "reset
parser state algorithm" is done in step 9 and not in step 5.1 together with
"Abort the stream append loop algorithm if it is running.".

I think this can create problems because the "reset parser state algorithm"
calls the coded frame processing algorithm which uses the values of abort mode,
appendWindowStart and appendWindowEnd which are reset as part of steps 6, 7 and
8 of the abort algorithm. So the remaining frames will not be appended

Additionally, calling the abort algorithm and resetting the parser state will
make the segment parser loop algorithm return in particular to the appendBuffer
algorithm (see step 11 of appendBuffer) and therefore run step 12, 13 and 14
(which would fire an update and a second update end event).

My suggestions would be:
- move abort step 9 as part of 5.1
- clarify that resetting parser state makes the segment parser loop algorithm
return with a code that avoids running step 12, 13 and 14.

You are receiving this mail because:
You are on the CC list for the bug.
Received on Friday, 22 March 2013 10:44:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:58 UTC