Bug 123926

Summary: [MSE] Validate the BCP47-ness of the language string passed to VideoTrack::setLanguage()
Product: WebKit Reporter: Jer Noble <jer.noble>
Component: New BugsAssignee: John Wilander <wilander>
Status: RESOLVED FIXED    
Severity: Normal CC: achristensen, buildbot, commit-queue, dbates, eric.carlson, jer.noble, manian, rniwa, webkit-bug-importer, wilander
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=166661
Attachments:
Description Flags
Patch
none
Archive of layout-test-results from ews102 for mac-yosemite
none
Archive of layout-test-results from ews117 for mac-yosemite
none
Archive of layout-test-results from ews107 for mac-yosemite-wk2
none
Archive of layout-test-results from ews122 for ios-simulator-wk2
none
Patch
none
Archive of layout-test-results from ews101 for mac-elcapitan
none
Archive of layout-test-results from ews107 for mac-elcapitan-wk2
none
Archive of layout-test-results from ews117 for mac-elcapitan
none
Archive of layout-test-results from ews121 for ios-simulator-wk2
none
Patch
none
Patch
none
Archive of layout-test-results from ews122 for ios-simulator-wk2
none
Patch none

Description Jer Noble 2013-11-06 14:14:10 PST
[MSE] Validate the BCP47-ness of the language string passed to VideoTrack::setLanguage()
Comment 1 John Wilander 2016-12-15 15:05:49 PST
Created attachment 297227 [details]
Patch
Comment 2 Jer Noble 2016-12-15 15:37:37 PST
Comment on attachment 297227 [details]
Patch

Nice! r=me
Comment 3 Build Bot 2016-12-15 16:02:40 PST
Comment on attachment 297227 [details]
Patch

Attachment 297227 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/2731653

New failing tests:
media/track/w3c/interfaces/TextTrack/language.html
imported/w3c/web-platform-tests/html/semantics/embedded-content/media-elements/interfaces/TextTrack/language.html
Comment 4 Build Bot 2016-12-15 16:02:43 PST
Created attachment 297240 [details]
Archive of layout-test-results from ews102 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews102  Port: mac-yosemite  Platform: Mac OS X 10.10.5
Comment 5 Build Bot 2016-12-15 16:11:59 PST
Comment on attachment 297227 [details]
Patch

Attachment 297227 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/2731662

New failing tests:
media/track/w3c/interfaces/TextTrack/language.html
imported/w3c/web-platform-tests/html/semantics/embedded-content/media-elements/interfaces/TextTrack/language.html
Comment 6 Build Bot 2016-12-15 16:12:02 PST
Created attachment 297243 [details]
Archive of layout-test-results from ews117 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews117  Port: mac-yosemite  Platform: Mac OS X 10.10.5
Comment 7 Build Bot 2016-12-15 16:17:13 PST
Comment on attachment 297227 [details]
Patch

Attachment 297227 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.webkit.org/results/2731722

New failing tests:
media/track/w3c/interfaces/TextTrack/language.html
imported/w3c/web-platform-tests/html/semantics/embedded-content/media-elements/interfaces/TextTrack/language.html
Comment 8 Build Bot 2016-12-15 16:17:16 PST
Created attachment 297246 [details]
Archive of layout-test-results from ews107 for mac-yosemite-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews107  Port: mac-yosemite-wk2  Platform: Mac OS X 10.10.5
Comment 9 Build Bot 2016-12-15 16:49:11 PST
Comment on attachment 297227 [details]
Patch

Attachment 297227 [details] did not pass ios-sim-ews (ios-simulator-wk2):
Output: http://webkit-queues.webkit.org/results/2731793

New failing tests:
media/only-bcp47-language-tags-accepted.html
Comment 10 Build Bot 2016-12-15 16:49:15 PST
Created attachment 297255 [details]
Archive of layout-test-results from ews122 for ios-simulator-wk2

The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews122  Port: ios-simulator-wk2  Platform: Mac OS X 10.11.6
Comment 11 John Wilander 2016-12-16 11:07:05 PST
I believe the W3C platform test is wrong (html/semantics/embedded-content/media-elements/interfaces/TextTrack/language.html).

Pull request:
https://github.com/w3c/web-platform-tests/pull/4359
Comment 12 Chris Dumez 2016-12-16 12:29:22 PST
Comment on attachment 297227 [details]
Patch

Based on discussion on the spec, I do not think we should land as is. The W3C test seems correct and should not fail.
Comment 13 John Wilander 2016-12-19 13:26:26 PST
After a discussion with Jer and Chris I will change this patch to only validate for internal purposes. This will allow the existing Web Platform test to continue working.
Comment 14 John Wilander 2016-12-19 20:18:32 PST
Created attachment 297503 [details]
Patch
Comment 15 John Wilander 2016-12-19 20:19:27 PST
Need a new review, please.
Comment 16 Build Bot 2016-12-19 21:21:00 PST
Comment on attachment 297503 [details]
Patch

Attachment 297503 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/2757285

New failing tests:
imported/w3c/web-platform-tests/html/dom/reflection-embedded.html
imported/w3c/web-platform-tests/html/semantics/embedded-content/media-elements/interfaces/HTMLElement/HTMLTrackElement/srclang.html
Comment 17 Build Bot 2016-12-19 21:21:03 PST
Created attachment 297505 [details]
Archive of layout-test-results from ews101 for mac-elcapitan

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews101  Port: mac-elcapitan  Platform: Mac OS X 10.11.6
Comment 18 Build Bot 2016-12-19 21:25:00 PST
Comment on attachment 297503 [details]
Patch

Attachment 297503 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.webkit.org/results/2757288

New failing tests:
imported/w3c/web-platform-tests/html/dom/reflection-embedded.html
imported/w3c/web-platform-tests/html/semantics/embedded-content/media-elements/interfaces/HTMLElement/HTMLTrackElement/srclang.html
Comment 19 Build Bot 2016-12-19 21:25:03 PST
Created attachment 297506 [details]
Archive of layout-test-results from ews107 for mac-elcapitan-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews107  Port: mac-elcapitan-wk2  Platform: Mac OS X 10.11.6
Comment 20 Build Bot 2016-12-19 21:35:06 PST
Comment on attachment 297503 [details]
Patch

Attachment 297503 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/2757284

New failing tests:
imported/w3c/web-platform-tests/html/semantics/embedded-content/media-elements/interfaces/HTMLElement/HTMLTrackElement/srclang.html
Comment 21 Build Bot 2016-12-19 21:35:09 PST
Created attachment 297508 [details]
Archive of layout-test-results from ews117 for mac-elcapitan

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews117  Port: mac-elcapitan  Platform: Mac OS X 10.11.6
Comment 22 Build Bot 2016-12-19 21:35:10 PST
Comment on attachment 297503 [details]
Patch

Attachment 297503 [details] did not pass ios-sim-ews (ios-simulator-wk2):
Output: http://webkit-queues.webkit.org/results/2757291

New failing tests:
imported/w3c/web-platform-tests/html/dom/reflection-embedded.html
media/only-bcp47-language-tags-accepted-as-valid.html
Comment 23 Build Bot 2016-12-19 21:35:14 PST
Created attachment 297509 [details]
Archive of layout-test-results from ews121 for ios-simulator-wk2

The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews121  Port: ios-simulator-wk2  Platform: Mac OS X 10.11.6
Comment 24 Daniel Bates 2016-12-20 10:45:55 PST
Comment on attachment 297503 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=297503&action=review

> Source/WebCore/html/HTMLMediaElement.cpp:3777
> +        LOG(Media, "HTMLMediaElement::configureTextTrackGroup(%p) -  '%s' track with language '%s' and BCP 47 language '%s' has score %i", this, textTrack->kindKeyword().string().utf8().data(), textTrack->language().string().utf8().data(), textTrack->validBCP47Language().string().utf8().data(), trackScore);

Nit: Although the format specifier %i is equivalent to %d for formatting a signed decimal number, a quick grep over the WebCore source code shows that we prefer %d.

> Source/WebCore/html/track/TrackBase.cpp:63
> +    // If the value being assigned to this attribute is not an empty string
> +    // or a BCP 47 language tag[BCP47], then abort these steps.

This comment states what the code does. A good comment explains "why" the code does is operations. Either explain why we need to do this (if it is not self-explanatory) or please remove this comment.

> Source/WebCore/html/track/TrackBase.cpp:75
> +    if (!language.isEmpty() && !isValidBCP47LanguageTag(language)) {
> +        String message;
> +        if (language.contains('\0'))
> +            message = WTF::ASCIILiteral("The language contains a null character and is not a valid BCP 47 language tag.");
> +        else {
> +            StringBuilder stringBuilder;
> +            stringBuilder.appendLiteral("The language '");
> +            stringBuilder.append(language);
> +            stringBuilder.appendLiteral("' is not a valid BCP 47 language tag.");
> +            message = stringBuilder.toString();
> +        }
> +        element()->document().addConsoleMessage(MessageSource::Rendering, MessageLevel::Warning, message);

Do other browsers emit a warning message for an invalid language? Neither <https://html.spec.whatwg.org/multipage/embedded-content.html#attr-track-srclang> nor <http://www.w3.org/TR/2016/PR-media-source-20161004/#sourcebuffer-init-segment-received> state that we need to emit a warning for an invalid language.

> Source/WebCore/html/track/TrackBase.cpp:79
> +    m_language = language;

<http://www.w3.org/TR/2016/PR-media-source-20161004/#sourcebuffer-init-segment-received> seems to imply that we should take language to be the empty string when the language string is not a valid BCP 47 identifier.

> LayoutTests/media/only-bcp47-language-tags-accepted-as-valid-expected.txt:155
> +EXPECTED (videoTrack.language == 'invalid-char-') OK

Is this what other browser do? According to <https://html.spec.whatwg.org/multipage/embedded-content.html#dom-videotrack-language> we should return an empty string for the track language:
[[
The AudioTrack.language and VideoTrack.language attributes must return the BCP 47 language tag of the language of the track, if it has one, or the empty string otherwise. If the user agent is not able to express that language as a BCP 47 language tag (for example because the language information in the media resource's format is a free-form string without a defined interpretation), then the method must return the empty string, as if the track had no language. [INBAND]
]]

> LayoutTests/media/only-bcp47-language-tags-accepted-as-valid.html:55
> +                    videoTrack.language = notOverwritten;

Would it make sense to test AudioTracks?
Comment 25 Daniel Bates 2016-12-20 10:59:43 PST
Comment on attachment 297503 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=297503&action=review

>> Source/WebCore/html/track/TrackBase.cpp:63
>> +    // or a BCP 47 language tag[BCP47], then abort these steps.
> 
> This comment states what the code does. A good comment explains "why" the code does is operations. Either explain why we need to do this (if it is not self-explanatory) or please remove this comment.

I know that you did not write this comment and though this comment did not reference a spec. the formatting, context lines, and the presence of a step numbers served as visual cues that this comment likely came from a spec. This comment comes from the an early revision of the Media Source Extensions spec. When you moved this comment you removed the leading sectional information and the step number, "10.1 language, on setting:\\1.", that served as visual cues. If we feel that there is value in annotating our code with the relevant spec legalese then we should reproduce such legalese verbatim. Even better we should update the comment to reference a permalink or a URL to the spec and mention the date so that a reader will know where the legalese came from and the version of the spec we implemented.

> Source/WebCore/html/track/VideoTrack.cpp:-205
> -    // 10.1 language, on setting:

Please do not remove this.

> Source/WebCore/html/track/VideoTrack.cpp:-208
> -    // 1. If the value being assigned to this attribute is not an empty string or a BCP 47 language
> -    // tag[BCP47], then abort these steps.
> -    // FIXME(123926): Validate the BCP47-ness of langague.

It seems weird that we are moving the validation logic out of this function that implements the spec. steps for processing a language. If the correct thing to do is to move the validation outside of this function then we should add a comment here that explains where the validation logic is located and even better explain why it could not be done here.

> Source/WebCore/html/track/VideoTrack.cpp:207
> -    // 3. If the sourceBuffer attribute on this track is not null, then queue a task to fire a simple
> +    // If the sourceBuffer attribute on this track is not null, then queue a task to fire a simple

Please do not remove the leading number. It serves as a visual cue that this line came from a spec. We update the top-most comment in this function to reference the spec.

> Source/WebCore/html/track/VideoTrack.cpp:212
> +    // Queue a task to fire a simple event named change at the VideoTrackList object referenced by

Ditto.

> Source/WebCore/platform/Language.cpp:204
> +bool isValidBCP47LanguageTag(const String& languageTag)
> +{
> +    if (languageTag.isEmpty())
> +        return false;
> +
> +    // https://tools.ietf.org/html/bcp47#section-2.1
> +    for (unsigned i = 0; i < languageTag.length(); ++i) {
> +        UChar c = languageTag[i];
> +        if (isASCIIAlphanumeric(c) || c == '-')
> +            continue;
> +        return false;
> +    }
> +    return true;
> +}

There is exactly one caller of this function in TrackBase::setLanguage(). Unless you plan to make use of this function in a subsequent bug/patch then I suggest we make this a static non-member, non-friend file function in file Source/WebCore/html/track/TrackBase.cpp.
Comment 26 John Wilander 2016-12-20 11:51:28 PST
(In reply to comment #24)
> Comment on attachment 297503 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=297503&action=review
> 
> > Source/WebCore/html/HTMLMediaElement.cpp:3777
> > +        LOG(Media, "HTMLMediaElement::configureTextTrackGroup(%p) -  '%s' track with language '%s' and BCP 47 language '%s' has score %i", this, textTrack->kindKeyword().string().utf8().data(), textTrack->language().string().utf8().data(), textTrack->validBCP47Language().string().utf8().data(), trackScore);
> 
> Nit: Although the format specifier %i is equivalent to %d for formatting a
> signed decimal number, a quick grep over the WebCore source code shows that
> we prefer %d.

Thanks. I'll change it as part of my patch.

> > Source/WebCore/html/track/TrackBase.cpp:63
> > +    // If the value being assigned to this attribute is not an empty string
> > +    // or a BCP 47 language tag[BCP47], then abort these steps.
> 
> This comment states what the code does. A good comment explains "why" the
> code does is operations. Either explain why we need to do this (if it is not
> self-explanatory) or please remove this comment.

Will comment on this in my reply to your follow-up.

> > Source/WebCore/html/track/TrackBase.cpp:75
> > +    if (!language.isEmpty() && !isValidBCP47LanguageTag(language)) {
> > +        String message;
> > +        if (language.contains('\0'))
> > +            message = WTF::ASCIILiteral("The language contains a null character and is not a valid BCP 47 language tag.");
> > +        else {
> > +            StringBuilder stringBuilder;
> > +            stringBuilder.appendLiteral("The language '");
> > +            stringBuilder.append(language);
> > +            stringBuilder.appendLiteral("' is not a valid BCP 47 language tag.");
> > +            message = stringBuilder.toString();
> > +        }
> > +        element()->document().addConsoleMessage(MessageSource::Rendering, MessageLevel::Warning, message);
> 
> Do other browsers emit a warning message for an invalid language? Neither
> <https://html.spec.whatwg.org/multipage/embedded-content.html#attr-track-
> srclang> nor
> <http://www.w3.org/TR/2016/PR-media-source-20161004/#sourcebuffer-init-
> segment-received> state that we need to emit a warning for an invalid
> language.

No, not that we know of we decided to do this because of two things:
1. We should help developers debug their code since with this change we will no longer accept non-compliant language tags internally. Without a warning there is no way for developers to understand what went wrong when their language setting is not picked up.
2. It allows for layout testing.

> > Source/WebCore/html/track/TrackBase.cpp:79
> > +    m_language = language;
> 
> <http://www.w3.org/TR/2016/PR-media-source-20161004/#sourcebuffer-init-
> segment-received> seems to imply that we should take language to be the
> empty string when the language string is not a valid BCP 47 identifier.

Are you saying we should drop the existing language setting (for internal use) if the page sets an invalid language? I actually implemented it that way first with just a boolean for whether m_language was valid or not.

If you mean language setting exposed to the page, see below.

> > LayoutTests/media/only-bcp47-language-tags-accepted-as-valid-expected.txt:155
> > +EXPECTED (videoTrack.language == 'invalid-char-') OK
> 
> Is this what other browser do? According to
> <https://html.spec.whatwg.org/multipage/embedded-content.html#dom-videotrack-
> language> we should return an empty string for the track language:
> [[
> The AudioTrack.language and VideoTrack.language attributes must return the
> BCP 47 language tag of the language of the track, if it has one, or the
> empty string otherwise. If the user agent is not able to express that
> language as a BCP 47 language tag (for example because the language
> information in the media resource's format is a free-form string without a
> defined interpretation), then the method must return the empty string, as if
> the track had no language. [INBAND]
> ]]

The discussion in my platform test pull request <https://github.com/w3c/web-platform-tests/pull/4359> ended with an acknowledgment that the spec is confusing but that BCP 47 compliance "is an authoring requirement, it does not affect user agents." We should just reflect to the page whatever the web developer decided to set. Thus the change only validates for internal purposes.

> > LayoutTests/media/only-bcp47-language-tags-accepted-as-valid.html:55
> > +                    videoTrack.language = notOverwritten;
> 
> Would it make sense to test AudioTracks?

We deliberately left AudioTrack out since it does not override TrackBase::setLanguage() and that was to be implemented in a follow-up patch by Jer. But since we moved validation to TrackBase::setLanguage() the validation will work for AudioTracks too and we should test it. Thanks!
Comment 27 John Wilander 2016-12-20 11:54:40 PST
(In reply to comment #25)
> Comment on attachment 297503 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=297503&action=review
> 
> >> Source/WebCore/html/track/TrackBase.cpp:63
> >> +    // or a BCP 47 language tag[BCP47], then abort these steps.
> > 
> > This comment states what the code does. A good comment explains "why" the code does is operations. Either explain why we need to do this (if it is not self-explanatory) or please remove this comment.
> 
> I know that you did not write this comment and though this comment did not
> reference a spec. the formatting, context lines, and the presence of a step
> numbers served as visual cues that this comment likely came from a spec.
> This comment comes from the an early revision of the Media Source Extensions
> spec. When you moved this comment you removed the leading sectional
> information and the step number, "10.1 language, on setting:\\1.", that
> served as visual cues. If we feel that there is value in annotating our code
> with the relevant spec legalese then we should reproduce such legalese
> verbatim. Even better we should update the comment to reference a permalink
> or a URL to the spec and mention the date so that a reader will know where
> the legalese came from and the version of the spec we implemented.

Got it. I'll restructure the comments and restore the proper spec quote.

> > Source/WebCore/html/track/VideoTrack.cpp:-205
> > -    // 10.1 language, on setting:
> 
> Please do not remove this.

Will fix.

> > Source/WebCore/html/track/VideoTrack.cpp:-208
> > -    // 1. If the value being assigned to this attribute is not an empty string or a BCP 47 language
> > -    // tag[BCP47], then abort these steps.
> > -    // FIXME(123926): Validate the BCP47-ness of langague.
> 
> It seems weird that we are moving the validation logic out of this function
> that implements the spec. steps for processing a language. If the correct
> thing to do is to move the validation outside of this function then we
> should add a comment here that explains where the validation logic is
> located and even better explain why it could not be done here.

I will add a comment.

> > Source/WebCore/html/track/VideoTrack.cpp:207
> > -    // 3. If the sourceBuffer attribute on this track is not null, then queue a task to fire a simple
> > +    // If the sourceBuffer attribute on this track is not null, then queue a task to fire a simple
> 
> Please do not remove the leading number. It serves as a visual cue that this
> line came from a spec. We update the top-most comment in this function to
> reference the spec.

Will fix.

> > Source/WebCore/html/track/VideoTrack.cpp:212
> > +    // Queue a task to fire a simple event named change at the VideoTrackList object referenced by
> 
> Ditto.

Will fix.

> > Source/WebCore/platform/Language.cpp:204
> > +bool isValidBCP47LanguageTag(const String& languageTag)
> > +{
> > +    if (languageTag.isEmpty())
> > +        return false;
> > +
> > +    // https://tools.ietf.org/html/bcp47#section-2.1
> > +    for (unsigned i = 0; i < languageTag.length(); ++i) {
> > +        UChar c = languageTag[i];
> > +        if (isASCIIAlphanumeric(c) || c == '-')
> > +            continue;
> > +        return false;
> > +    }
> > +    return true;
> > +}
> 
> There is exactly one caller of this function in TrackBase::setLanguage().
> Unless you plan to make use of this function in a subsequent bug/patch then
> I suggest we make this a static non-member, non-friend file function in file
> Source/WebCore/html/track/TrackBase.cpp.

The plan is to reuse this in HTTP header validation of Accept-Language and Content-language. But I don't know when that will happen. Would you prefer this to be a static non-member for now and then open it up when needed?
Comment 28 Daniel Bates 2016-12-20 13:17:49 PST
(In reply to comment #26)
> > > Source/WebCore/html/track/TrackBase.cpp:75
> > > +    if (!language.isEmpty() && !isValidBCP47LanguageTag(language)) {
> > > +        String message;
> > > +        if (language.contains('\0'))
> > > +            message = WTF::ASCIILiteral("The language contains a null character and is not a valid BCP 47 language tag.");
> > > +        else {
> > > +            StringBuilder stringBuilder;
> > > +            stringBuilder.appendLiteral("The language '");
> > > +            stringBuilder.append(language);
> > > +            stringBuilder.appendLiteral("' is not a valid BCP 47 language tag.");
> > > +            message = stringBuilder.toString();
> > > +        }
> > > +        element()->document().addConsoleMessage(MessageSource::Rendering, MessageLevel::Warning, message);
> > 
> > Do other browsers emit a warning message for an invalid language? Neither
> > <https://html.spec.whatwg.org/multipage/embedded-content.html#attr-track-
> > srclang> nor
> > <http://www.w3.org/TR/2016/PR-media-source-20161004/#sourcebuffer-init-
> > segment-received> state that we need to emit a warning for an invalid
> > language.
> 
> No, not that we know of we decided to do this because of two things:
> 1. We should help developers debug their code since with this change we will
> no longer accept non-compliant language tags internally. Without a warning
> there is no way for developers to understand what went wrong when their
> language setting is not picked up.
> 2. It allows for layout testing.
> 

OK. Is it necessary to include the language or whether it includes a null character in the error message? Can we take advantage of the facts that the track.srclang/texttrack.language attribute represents a single BCP 47 identifier (is this true?) and that a console message has line information to emit a generic error message? I also suggest that the error message explain how WebKit is handling this malformed language. (Are we ignoring the value of track.srclang/texttrack.language? What does it mean to ignore the text track language?)
Comment 29 Daniel Bates 2016-12-20 13:30:10 PST
(In reply to comment #26)
> > > Source/WebCore/html/track/TrackBase.cpp:79
> > > +    m_language = language;
> > 
> > <http://www.w3.org/TR/2016/PR-media-source-20161004/#sourcebuffer-init-
> > segment-received> seems to imply that we should take language to be the
> > empty string when the language string is not a valid BCP 47 identifier.
> 
> Are you saying we should drop the existing language setting (for internal
> use) if the page sets an invalid language? 

Disregard my comment as it does not seem applicable to this patch.
Comment 30 Daniel Bates 2016-12-20 13:30:20 PST
(In reply to comment #27)
> > > Source/WebCore/platform/Language.cpp:204
> > > +bool isValidBCP47LanguageTag(const String& languageTag)
> > > +{
> > > +    if (languageTag.isEmpty())
> > > +        return false;
> > > +
> > > +    // https://tools.ietf.org/html/bcp47#section-2.1
> > > +    for (unsigned i = 0; i < languageTag.length(); ++i) {
> > > +        UChar c = languageTag[i];
> > > +        if (isASCIIAlphanumeric(c) || c == '-')
> > > +            continue;
> > > +        return false;
> > > +    }
> > > +    return true;
> > > +}
> > 
> > There is exactly one caller of this function in TrackBase::setLanguage().
> > Unless you plan to make use of this function in a subsequent bug/patch then
> > I suggest we make this a static non-member, non-friend file function in file
> > Source/WebCore/html/track/TrackBase.cpp.
> 
> The plan is to reuse this in HTTP header validation of Accept-Language and
> Content-language. But I don't know when that will happen. Would you prefer
> this to be a static non-member for now and then open it up when needed?

Are you planing to reuse this the HTTP header validation logic in a patch in the near future (as in the next day or two)? If not, then I suggest that we make this a static non-member, non-friend file function in file Source/WebCore/html/track/TrackBase.cpp. When we come around to update the HTTP header validation logic then we can move this function to an appropriate place (maybe this file) so that it can be shared between the text track machinery and the HTTP header validation logic.
Comment 31 John Wilander 2016-12-22 17:21:08 PST
Created attachment 297693 [details]
Patch
Comment 32 John Wilander 2016-12-22 17:40:55 PST
Created attachment 297695 [details]
Patch
Comment 33 John Wilander 2016-12-22 17:42:54 PST
The GTK build was complaining about ambiguity in AtomicString::contains() for the call language.contains('\0').
Comment 34 Build Bot 2016-12-22 19:00:04 PST
Comment on attachment 297695 [details]
Patch

Attachment 297695 [details] did not pass ios-sim-ews (ios-simulator-wk2):
Output: http://webkit-queues.webkit.org/results/2772708

New failing tests:
imported/w3c/web-platform-tests/html/dom/reflection-embedded.html
media/only-bcp47-language-tags-accepted-as-valid.html
Comment 35 Build Bot 2016-12-22 19:00:09 PST
Created attachment 297701 [details]
Archive of layout-test-results from ews122 for ios-simulator-wk2

The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews122  Port: ios-simulator-wk2  Platform: Mac OS X 10.11.6
Comment 36 John Wilander 2017-01-03 18:08:52 PST
Created attachment 297978 [details]
Patch
Comment 37 Jer Noble 2017-01-03 20:30:51 PST
Comment on attachment 297978 [details]
Patch

r=me. Nice job!
Comment 38 John Wilander 2017-01-04 10:59:48 PST
Thanks! Committing. I'll update it if Alex has further comments (we all discussed the rather complex validation logic).
Comment 39 WebKit Commit Bot 2017-01-04 11:22:40 PST
Comment on attachment 297978 [details]
Patch

Clearing flags on attachment: 297978

Committed r210280: <http://trac.webkit.org/changeset/210280>
Comment 40 WebKit Commit Bot 2017-01-04 11:22:49 PST
All reviewed patches have been landed.  Closing bug.
Comment 41 Radar WebKit Bug Importer 2017-10-18 12:41:08 PDT
<rdar://problem/35058112>