New issue
Advanced search Search tips
Starred by 1 user

Issue metadata

Status: Fixed
Closed: Sep 2016
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

issue 651572

Sign in to add a comment

Issue 651777: WebVTT parser tests, signature-formfeed.vtt web-platform-test failing in Chrome, passes in Edge and Firefox

Reported by, Sep 30 2016 Project Member

Issue description

The subtest "WebVTT parser tests, signature-formfeed.vtt" is failing in Chrome but passes in Firefox and Edge.

Firefox in fact passes all of these tests, but most of Chrome's failures are due to  issue 617989 .

Comment 1 by, Sep 30 2016

Status: Assigned (was: Untriaged)
Ok, let's assume the dust has settled around the allowed WS after the signature now =)

Comment 3 by, Sep 30 2016

Status: Fixed (was: Assigned)

Comment 4 by, Sep 30 2016

No use counter, I presume? :S

Comment 5 by, Sep 30 2016

No, but for the form-feed character alone I think that would've been severe overkill - form-feed has after all never been syntactically allowed (i.e it's been part of error-handling.)

Comment 6 by, Sep 30 2016

Oh, so the text track yielded no subtitles anyway, but did not fire an error event and cues.length did not throw, right?
If so, code can break as a result of the throwing...

Comment 7 by, Sep 30 2016

No, there was a difference (in the spec) between syntax and the parsing algorithm (the former didn't allow form-feed while the latter did because it is more lenient by design.) There's no exceptions involved, but if you had a file with "WEBVTT<U+000C>gazonk" as the signature the load will now fail (fire 'error' instead of 'load') and cues.length will be zero (not throw. There'll also still be a track and a cue list, just empty.)

Comment 8 by, Sep 30 2016

Oh, so the "load" event will not fire from now on. I agree it is an edge case, but I am not completely comfortable without a use counter. But I guess I am just paranoid and the ship has sort of sailed.

Thank you.

Sign in to add a comment