This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 21374 - Clarify abort algorithm
Summary: Clarify abort algorithm
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Media Source Extensions (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Aaron Colwell (c)
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-22 10:44 UTC by Cyril Concolato
Modified: 2013-03-26 17:59 UTC (History)
3 users (show)

See Also:


Attachments

Description Cyril Concolato 2013-03-22 10:44:46 UTC
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 properly.

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.
Comment 1 Cyril Concolato 2013-03-22 16:22:09 UTC
Actually, since steps 11-14 in the appendBuffer are dependent on the return of the segment parser loop, they are not synchronous and should be part of the segment parser loop algo directly.

Also, what is supposed to happen if the abort call is made when the segment parser loop is already running?
Comment 2 Aaron Colwell (c) 2013-03-25 20:28:33 UTC
(In reply to comment #0)
> 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.".

It is done in step 9 because abort() can be called when there isn't a pending append operation. The substeps in 5 are only run when there is an active append operation pending.

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

You are partially correct. I'll move step 9 to step 6 and shift 6-8 down by one. I believe this resolves this issue.

> down by one
> 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).

No. That was not the intent. The segment parser loop only returns control to the calling algorithm in step 7. I'll rework the text so that it is clear that the calling algorithm is also aborted if the segment parser loop algorithm is aborted.

> 
> 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.
Comment 3 Aaron Colwell (c) 2013-03-26 17:59:22 UTC
Changes committed.
https://dvcs.w3.org/hg/html-media/rev/1e6898152c5b