This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Before I brought up that there was a mismatch between the text/vtt registration's "WebVTT files all begin with one of the following byte sequences:" and the WebVTT parser's handling of the signature. Hixie made a change to the parser to address it, but they still don't match. Consider a file that contains "WEBVTT foo" and no LFs. It matches the text/vtt's registration, but the parser rejects it in step 9, because there's no LF. I think the parser step 5 should be changed to collect characters that are not LF, space or tab, and then check that the collected characters are "WEBVTT", and then if the next character is space or tab, skip characters that are not LF, and remove step 9.
This seems like it was fixed to me. Parser step 5 collects "WEBVTT foo" into /line/. Step 9 aborts, but doesn't reject it, it explicitly says it was successfully processed. There'd be no point continuing with the algorithm, since there's no more data — step 10 would walk off the end of the string, step 11 would find no characters, and step 12 would skip to the end, which says basically the same as step 9.