Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-fonts-4] Contribute Microsoft tests for Font Variations #9373

Merged
merged 10 commits into from Apr 3, 2018

Conversation

@FremyCompany
Copy link
Contributor

FremyCompany commented Feb 2, 2018

Contributing (most) of our own CSS Fonts 4 tests to web-platform-tests. Some tests have not been ported because they require Microsoft Windows fonts and I have not enough time/expertise to create a dummy version of these fonts.

INTEROP: Chrome, Safari and Firefox all seem to have issues with these tests, so it would be good if someone from either/all of these browsers could review the tests.

NOTE: One of the test requires you to install some fonts natively on your system. These fonts are a new (but backward-compatible) version of the fonts that are already required for other css-fonts tests. I created this new version because the old version didn't give any mean to test font matching via JavaScript, which is annoying. If this PR gets merged, someone should update http://www.w3.org/Style/CSS/Test/Fonts/CSSTest/ but I don't know who to contact.

@w3c-bots

This comment has been minimized.

Copy link

w3c-bots commented Feb 2, 2018

Build PASSED

Started: 2018-03-06 23:56:51
Finished: 2018-03-07 00:34:28

Failing Jobs

  • MicrosoftEdge:16.16299

View more information about this build on:

@@ -0,0 +1,38 @@
<!DOCTYPE html>

This comment has been minimized.

Copy link
@SergeyMalkin

SergeyMalkin Feb 2, 2018

This is not variable fonts test, so you may want to move it outside variations folder. But otherwise test is useful and should also be expanded to test access to individual fonts inside collection.


<script>
testFontShorthand = [
{ value: "calc(24px) Arial", isValid:true, message: "Font weight specified as number" },

This comment has been minimized.

Copy link
@SergeyMalkin

SergeyMalkin Feb 2, 2018

Comment is incorrect. This should be something like "font-weight and font-style are not part of shorthand"

@FremyCompany

This comment has been minimized.

Copy link
Contributor Author

FremyCompany commented Feb 3, 2018

Linting errors I will have to fix:

  • TRAILING WHITESPACE: 1
  • AHEM COPY: 1
  • CR AT EOL: 940
  • MISSING-LINK: 13
@SergeyMalkin

This comment has been minimized.

Copy link

SergeyMalkin commented Feb 3, 2018

You forgot to port two files: extensive set of font matching tests and also tests for parsing @font-face descriptors.

{ value: "oblique 100deg 24px Arial", isValid:false, message: "'oblique' with negative angle, value out of range" },
{ value: "oblique -100deg 24px Arial", isValid:false, message: "'oblique' with positive angle, value out of range" },
// font-weight adn font-style combined

This comment has been minimized.

Copy link
@SergeyMalkin

SergeyMalkin Feb 3, 2018

Nit: adn -> and. Same few lines below

];
testStretchValues.forEach(function (element) {
test(() => { assert_equals(window.CSS.supports("font-stretch", element.stretch), element.expectedIsSupported, element.message); }, "@supports: " + element.stretch + " - " + element.message);

This comment has been minimized.

Copy link
@SergeyMalkin

SergeyMalkin Feb 3, 2018

Nit: new line after { and indent whole block

<body onload="test()">
<div id="opentype" style="display:inline-block; font-family:OpenType,Georgia;">Test</div><br>
<div id="collection" style="display:inline-block; font-family:OpenType-Collection,Verdana;">Test</div>
<script>

This comment has been minimized.

Copy link
@SergeyMalkin

SergeyMalkin Feb 3, 2018

Add "use strict"

<body>
<div id="shorthand-test">Shorthand test</div>

<script>

This comment has been minimized.

Copy link
@SergeyMalkin

SergeyMalkin Feb 3, 2018

Add "use strict"

<body>
<div id="computedStyleTest">Abc</span></div>
<div id="inheritanceTest"><span style="font-stretch:125%;">Abc</span><span style="font-stretch:expanded;">Abc</span><span style="font-weight: 700;">Abc</span></div>
<script>

This comment has been minimized.

Copy link
@SergeyMalkin

SergeyMalkin Feb 3, 2018

Add "use strict"

<script src="/resources/testharness.js"></script>
<script src="/resources/testharnessreport.js"></script>
<style>
@keyframes fontStyleAnimation {

This comment has been minimized.

Copy link
@SergeyMalkin

SergeyMalkin Feb 3, 2018

fontStyleAnimation -> fontWeightAnimation

<script src="/resources/testharnessreport.js"></script>
</head>
<body>
<script>

This comment has been minimized.

Copy link
@SergeyMalkin

SergeyMalkin Feb 3, 2018

Add "use strict"

<body>
<script>
valueParserTests = [
{ input: "'wght' 1000, '9 ~A' -45", output: "\"9 ~A\" -45, \"wght\" 1000", valid: true, message: "Axis tag with valid non-letter ascii characters" },

This comment has been minimized.

Copy link
@SergeyMalkin

SergeyMalkin Feb 3, 2018

Would be nice to have names consistent between tests, e.g. input/output/valid->value/expectedComputedValue/isValid

</div>
</div>

<script>

This comment has been minimized.

Copy link
@SergeyMalkin
{ weight: "1000.001", isValid: false, message: "Values above maximum should be rejected" },
{ weight: "calc(100.5)", isValid: true, expectedStyle: "100.5", message: "Simple calc value" },
{ weight: "calc(1001)", isValid: false, message: "Out-of-range simple calc value" },
{ weight: "calc(100.5*3 + 50.5)", isValid: true, expectedStyle: "352", message: "Valid calc expression" },

This comment has been minimized.

Copy link
@SergeyMalkin

SergeyMalkin Feb 3, 2018

expectedStyle -> expectedWeight

@emilio

This comment has been minimized.

Copy link
Contributor

emilio commented Feb 4, 2018

{ style: "oblique -a", expectedResult: false, message: "'oblique' followed by minus and non-number is invalid" }
{ style: "oblique -a", expectedResult: false, message: "'oblique' followed by minus and non-number is invalid" },
{ style: "oblique calc(50deg)", expectedResult: true, message: "'oblique' followed by calc is valid" },
{ style: "oblique calc(-120deg)", expectedResult: true, message: "'oblique' followed by calc is valid even if it must be clamped (no computation)" },

This comment has been minimized.

Copy link
@SergeyMalkin

SergeyMalkin Feb 5, 2018

Can you add cases for different angle units? E.g. calc(2 * 0.1rad)

This comment has been minimized.

Copy link
@FremyCompany

FremyCompany Feb 5, 2018

Author Contributor

I doubt that this is relevant. A browser that would fail these tests but not the existing ones would have an issue with css-value-and-units not font-style parsing.

This comment has been minimized.

Copy link
@SergeyMalkin

SergeyMalkin Feb 6, 2018

Are there tests for css-values to cover calc() for angles? I don't see any, but I may be missing it.

There are specific tests covering other properties and units. We should have tests for angles, either here or in css-values folder

{ style: "oblique -a", expectedResult: false, message: "'oblique' followed by minus and non-number is invalid" }
{ style: "oblique -a", expectedResult: false, message: "'oblique' followed by minus and non-number is invalid" },
{ style: "oblique calc(50deg)", expectedResult: true, message: "'oblique' followed by calc is valid" },
{ style: "oblique calc(-120deg)", expectedResult: true, message: "'oblique' followed by calc is valid even if it must be clamped (no computation)" },

This comment has been minimized.

Copy link
@SergeyMalkin

SergeyMalkin Feb 5, 2018

Are you sure calc(-120deg) is valid value? My understanding is that final calculated value is tested against acceptable range, otherwise it is treated as parse error.

This comment has been minimized.

This comment has been minimized.

Copy link
@SergeyMalkin

SergeyMalkin Feb 5, 2018

Ah, ok. Then both Edge and Chrome have the same bug across font-weight/stretch/style.

Can you review font-weight and font-stretch tests? (including @font-face descriptor tests)

@wpt-pr-bot wpt-pr-bot added the infra label Feb 5, 2018

@wpt-pr-bot wpt-pr-bot requested a review from jgraham Feb 5, 2018

@drott

This comment has been minimized.

Copy link
Contributor

drott commented Feb 6, 2018

INTEROP: Chrome, Safari and Firefox all seem to have issues with these tests, so it would be good if someone from either/all of these browsers could review the tests.

Thanks for upstreaming and contributing these, @FremyCompany. I will put it on my TODO list to go through them for Blink and leave review feedback accordingly, but it will take a bit more time.

@FremyCompany

This comment has been minimized.

Copy link
Contributor Author

FremyCompany commented Feb 7, 2018

@drott Thanks, totally understood

@drott
Copy link
Contributor

drott left a comment

An excellent quality set of test cases - very helpful, thank you! Running these in Blink already uncovered 9 issues (compare this meta bug).

I got curious about these test cases so I gave them a go in Blink. 2 pass as is, 10 fail, some of them only with minor issus.

For the test cases that partially need system fonts, I would suggest to split those out into separate tests for making it easier to compare results across engines, as the manual installation / harness preparation with the system fonts is an extra step that automated testing might not cover well yet.

I don't agree with the expectations for css/css-fonts/variations/font-variation-settings-inherit.html. But this might be only my interpretation of the spec or I might have missed something. It seems we need a spec clarification here. If you'd like to merge this PR quickly, I would suggest to isolate this one into a separate PR until we work out with @litherum and others what the expected behavior should be.

Some test cases trigger a harness error / warning for duplicate test names. I believe this is minor but probably worth fixing.

Thanks again, I am happy to straighten out the Blink issues to pass more of these new tests.

<link rel="help" href="https://www.w3.org/TR/css-fonts-4/#font-matching-algorithm" />
<script src="../../../../resources/testharness.js"></script>
<script src="../../../../resources/testharnessreport.js"></script>
<!-- PART OF THIS TEST REQUIRES THAT YOU INSTALL THE [csstest-*.ttf] FONTS OF THE [resources] FOLDER -->

This comment has been minimized.

Copy link
@drott

drott Feb 7, 2018

Contributor

Minor: If it's not too much trouble, if there are parts of this test that do not require the system fonts installed, would it be possible to split this test into one for the system font parts, one for the web fonts parts?

This comment has been minimized.

Copy link
@FremyCompany

FremyCompany Feb 7, 2018

Author Contributor

Seems reasonable, will do

This comment has been minimized.

Copy link
@FremyCompany

FremyCompany Feb 7, 2018

Author Contributor

✔ (this test didn't require the fonts to be installed, I converted it to use linked fonts)

@@ -0,0 +1,135 @@
<!DOCTYPE html>

This comment has been minimized.

Copy link
@drott

drott Feb 7, 2018

Contributor

The test looks reasonable to me, although I can't validate it with too much confidence as we currently do not support variable system fonts in Chrome.

{ value: "1700.5 24px Arial", isValid:false, message: "Font weight specified as number, value greater than 1000" },
// font-weight as calc()
{ value: "calc(900.5 - 200.1 * 2) calc(12px + 12px) Arial", isValid:true, expectedWeight:"500.3", message: "Font weight specified as calc()" },

This comment has been minimized.

Copy link
@drott

drott Feb 7, 2018

Contributor

We allow 1/4 increments for stretch, style, weight font selection parameters, so on Blink this results in 500.25. Perhaps you could make the test tolerant to that?

This comment has been minimized.

Copy link
@FremyCompany

FremyCompany Feb 7, 2018

Author Contributor

Yes, I can make the calc land on a 0.5 multiple.

This comment has been minimized.

Copy link
@FremyCompany

FremyCompany Feb 7, 2018

Author Contributor

// font-weight as calc()
{ value: "calc(900.5 - 200.1 * 2) calc(12px + 12px) Arial", isValid:true, expectedWeight:"500.3", message: "Font weight specified as calc()" },
{ value: "calc(400.5 - 200.1 * 2) 24px Arial", isValid:false, message: "Font weight specified as calc(), value less than 1" },

This comment has been minimized.

Copy link
@drott

drott Feb 7, 2018

Contributor

Nice!

This comment has been minimized.

Copy link
@FremyCompany

FremyCompany Feb 7, 2018

Author Contributor

On second look though, this expression should be valid though, because of calc() clamping.
I will update the expectation here ^_^

This comment has been minimized.

Copy link
@FremyCompany

FremyCompany Feb 7, 2018

Author Contributor

// font-style
{ value: "oblique 45deg 24px Arial", isValid:true, expectedStyle: "oblique 45deg", message: "'oblique' with positive angle" },
{ value: "oblique -45deg 24px Arial", isValid:true, expectedStyle: "oblique -45deg", message: "'oblique' with hegative angle" },
{ value: "oblique 24px Arial", isValid:true, expectedStyle: "oblique", message: "'oblique' without slant angle" },

This comment has been minimized.

Copy link
@drott

drott Feb 7, 2018

Contributor

Not really a review comment, just sharing the Blink perspective: As far as I interpret the spec, there is no clear distinction anymore for oblique/italic as long as there is no angle specified. At least that is the case for the font matching algorithm. So internally we store italic and oblique (without angle) as the same value, and the computed style comes back as "italic" since it can't tell them apart. This may be a bug, but since UAs are not required to distinguish oblique and italic for matching, the test might be rather strict here.

This comment has been minimized.

Copy link
@FremyCompany

FremyCompany Feb 7, 2018

Author Contributor

I think it's fine to leave the test strict here, but it's also probably ok not to pass that specific test, I doubt this is going to cause much webcompat trouble ^_^

I think there's still supposed to be a different between oblique and italic if a font supports both. It seems oblique shoud (I think but I'm not entirely sure) prefer any oblique fontface over the italic fontface, while italic should prefer any italic version of an oblique fontface.

I have never seen a font with both an oblique and an italic variant though, so I am not sure how to test whether this is true in any browser. Maybe the LaTeX font?

This comment has been minimized.

Copy link
@FremyCompany

FremyCompany Feb 7, 2018

Author Contributor

✔ (no change)

This comment has been minimized.

Copy link
@jfkthame

jfkthame Feb 7, 2018

Contributor

Yes, the Computer Modern (or the newer Latin Modern) family offers both oblique ("slanted") and italic, and indeed they are used contrastively by some authors (e.g. Knuth himself).

(It also has an Unslanted Italic face, which AFAICS is not something we could express with CSS according to the current draft. I suppose something like

font-style: italic oblique(0deg);

would make sense, if we want to allow it, but currently that would be a parse error.)

CSS Fonts 3 made it quite clear that 'italic' and 'oblique' could be distinguished, at least in @font-face families even if the UA doesn't support a distinction for system font families. I don't see any reason why we should regress that in Fonts 4.

This comment has been minimized.

Copy link
@svgeesus

svgeesus Feb 9, 2018

Contributor

Indeed, Fonts 4 makes it clear that oblique takes an optional second parameter, the oblique angle; and oblique now expands to oblique 20deg.

<script>
var valueParserTests = [
{ value: "'wght' 1000, '9 ~A' -45", expectedComputedValue: "\"9 ~A\" -45, \"wght\" 1000", isValid: true, message: "Axis tag with valid non-letter ascii characters" },

This comment has been minimized.

Copy link
@drott

drott Feb 7, 2018

Contributor

There are some duplicate test names here, perhaps you can add a counter, as suggested above.
Harness Error. harness_status.status = 1 , harness_status.message = 4 duplicate test names: "Property value: Percentages should not be supported", "Property value: Units should not be supported", "@supports: Percentages should not be supported", "@supports: Units should not be supported"

Also, good point about the valid character range issues, Blink issue filed.

This comment has been minimized.

Copy link
@FremyCompany

FremyCompany Feb 7, 2018

Author Contributor

This comment has been minimized.

Copy link
@csnardi

csnardi Mar 1, 2018

Member

This still seems to exist, looking at the Travis log:

`Property value: Percentages should not be supported` | **FAIL: 20/10** 
`@supports: Percentages should not be supported` | **PASS: 20/10**
{ value: "'wght' 1000, '9 ~A' -45", expectedComputedValue: "\"9 ~A\" -45, \"wght\" 1000", isValid: true, message: "Axis tag with valid non-letter ascii characters" },
{ value: "'\u001Fbdc' 123", expectedComputedValue: "", isValid: false, message: "Invalid character below allowed range"},
{ value: "'abc\u007F' 123", expectedComputedValue: "", isValid: false, message: "Invalid character above allowed range"},
{ value: "'wght' 1e3, 'slnt' -450.0e-1 ", expectedComputedValue: "\"slnt\" -45, \"wght\" 1000", isValid: true, message: "Axis values in scientific form are valid" },

This comment has been minimized.

Copy link
@drott

drott Feb 7, 2018

Contributor

Interesting :), Blink issue filed.

@@ -0,0 +1,58 @@
<!DOCTYPE html>

This comment has been minimized.

Copy link
@drott

drott Feb 7, 2018

Contributor

Nice test case, thank you, some work for us here.

<script src="/resources/testharness.js"></script>
<script src="/resources/testharness.js"></script>
<script src="/resources/testharnessreport.js"></script>
<!-- PART OF THIS TEST REQUIRES THAT YOU INSTALL THE [csstest-*.ttf] FONTS OF THE [resources] FOLDER -->

This comment has been minimized.

Copy link
@drott

drott Feb 7, 2018

Contributor

May I also suggest for this test to split out the part of the test that matches against system fonts?

This comment has been minimized.

Copy link
@FremyCompany

FremyCompany Feb 7, 2018

Author Contributor

Seems reasonable

This comment has been minimized.

Copy link
@FremyCompany

FremyCompany Feb 7, 2018

Author Contributor

✔ (splitted test in two)

var testContinuousWeights = [
{ weight: "401", isValid: true, message: "Values that are not multiple of 100 should be parsed successfully" },
{ weight: "400.1", isValid: true, message: "Non-integer Values should be parsed successfully" },

This comment has been minimized.

Copy link
@drott

drott Feb 7, 2018

Contributor

We fail this one, but not because of a parsing error. It's because we internally only represent 400.0 and 400.25 - so it's 400.1 != 400 in the assertion. You seem to internally represent 0.1 increments. May I suggest to change this to 400.5? Or would you find that a hack?

This comment has been minimized.

Copy link
@FremyCompany

FremyCompany Feb 7, 2018

Author Contributor

I will change to 400.5

This comment has been minimized.

Copy link
@FremyCompany

FremyCompany Feb 7, 2018

Author Contributor

@FremyCompany

This comment has been minimized.

Copy link
Contributor Author

FremyCompany commented Feb 7, 2018

For the test cases that partially need system fonts, I would suggest to split those out into separate tests for making it easier to compare results across engines, as the manual installation / harness preparation with the system fonts is an extra step that automated testing might not cover well yet.

Done.

I also converted to url() fonts some tests that unnecessarily relied on the fonts being available.

I don't agree with the expectations for css/css-fonts/variations/font-variation-settings-inherit.html. But this might be only my interpretation of the spec or I might have missed something. It seems we need a spec clarification here. If you'd like to merge this PR quickly, I would suggest to isolate this one into a separate PR until we work out with @litherum and others what the expected behavior should be.

I updated the test to have a generic-enough assertion it passes in both browsers. We can always refine in a further pull request when we have the expected behavior clarified in the spec.

@drott

drott approved these changes Feb 8, 2018

Copy link
Contributor

drott left a comment

Thanks for addressing the comments, LGTM. I'll file an issue for the inheritance / precedence of duplicate axis tags questions.

test(() => {
var actualValue = window.getComputedStyle(elementParent).fontVariationSettings;
// The following strict test is subject to debate; softening for now:

This comment has been minimized.

Copy link
@drott

This comment has been minimized.

Copy link
@svgeesus

svgeesus Feb 9, 2018

Contributor

@drott did you want to hold off on approving all tests while that issue gets discussed, or approve all but that test, or approve all and then fix up if needed?

This comment has been minimized.

Copy link
@drott

drott Feb 9, 2018

Contributor

I am good with merging the more lenient version of this test and discussing on the separate issue in the meantime.

I did approve the PR, see above "drott approved these changes 23 hours ago", but it seems like that doesn't count 😢.

"Review required
At least one approved review is required by reviewers with write access. "

Would I be eligible for write access, who could configure it for me?

This comment has been minimized.

Copy link
@svgeesus

svgeesus Feb 14, 2018

Contributor

Would I be eligible for write access, who could configure it for me?

I just did, #9525 but now that tiny edit needs a reviewer ...

@svgeesus

This comment has been minimized.

Copy link
Contributor

svgeesus commented Feb 9, 2018

@FremyCompany

If this PR gets merged, someone should update http://www.w3.org/Style/CSS/Test/Fonts/CSSTest/ but I don't know who to contact.

That would be me. But discuss with CSS WG first as there have been several updates to Ahem over recent years and we want to be sure the new one is a true superset of the most recent previous update (plus there was quite some discussion as I recall).

@FremyCompany

This comment has been minimized.

Copy link
Contributor Author

FremyCompany commented Feb 10, 2018

@svgeesus I didn't update Ahem so that shouldn't be a problem.

I updated the CSSTest fonts that are currently provided at the url pointed above. I manually checked all the tests that are using those fonts, and they didn't regress based on the update, so I think we should be fine.

@svgeesus
Copy link
Contributor

svgeesus left a comment

Approved (once the build passes)

@svgeesus svgeesus referenced this pull request Feb 14, 2018

Merged

Add @drott #9525

@FremyCompany

This comment has been minimized.

Copy link
Contributor Author

FremyCompany commented Feb 16, 2018

@svgeesus The build now passes everything but the Firefox run. It does not fail because of me, it fails because it cannot seem to start any web platform test. After 24mins, it gave up. I think we should merge this, and someone from the infra team should take a look at what is going on.

I can't merge because your review is marked as "requiring changes" though.

@drott

This comment has been minimized.

Copy link
Contributor

drott commented Mar 1, 2018

@svgeesus ping? Can you help getting this merged, thank you!

@csnardi
Copy link
Member

csnardi left a comment

It looks like the Firefox build was actually failing, which would prevent this from being merged.

<script>
var valueParserTests = [
{ value: "'wght' 1000, '9 ~A' -45", expectedComputedValue: "\"9 ~A\" -45, \"wght\" 1000", isValid: true, message: "Axis tag with valid non-letter ascii characters" },

This comment has been minimized.

Copy link
@csnardi

csnardi Mar 1, 2018

Member

This still seems to exist, looking at the Travis log:

`Property value: Percentages should not be supported` | **FAIL: 20/10** 
`@supports: Percentages should not be supported` | **PASS: 20/10**
{ style: "oblique 90deg", expectedResult: true, message: "'oblique' followed by maxumum 90 degree angle is valid" },
{ style: "oblique -90deg", expectedResult: true, message: "'oblique' followed by minimum -90 degree angle is valid" },
{ style: "oblique 90.01deg", expectedResult: false, message: "'oblique' followed by positive out of range angle is in invalid" },
{ style: "oblique -90.01deg", expectedResult: false, message: "'oblique' followed by positive out of range angle is in invalid" },

This comment has been minimized.

Copy link
@csnardi

csnardi Mar 1, 2018

Member

Another duplicate test name:

`Font-style: 'oblique' followed by positive out of range angle is in invalid` | **PASS: 20/10**

This comment has been minimized.

Copy link
@FremyCompany

FremyCompany Mar 6, 2018

Author Contributor

Ah, that's what 20/10 means. That wasn't clear to me. Hopefully fixed now?

@FremyCompany

This comment has been minimized.

Copy link
Contributor Author

FremyCompany commented Mar 7, 2018

Thanks @csnardi that was indeed it 🙌
@svgeesus would you mind merging the pull request now?

@FremyCompany

This comment has been minimized.

Copy link
Contributor Author

FremyCompany commented Mar 20, 2018

@svgeesus svgeesus merged commit 0030814 into master Apr 3, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@foolip foolip deleted the user/frremy/contribute-css-fonts-4-tests branch Apr 4, 2018

@foolip

This comment has been minimized.

Copy link
Contributor

foolip commented Apr 4, 2018

Tests are great! This revealed a failing assert in Chromium:
https://bugs.chromium.org/p/chromium/issues/detail?id=828746

aarongable pushed a commit to chromium/chromium that referenced this pull request Apr 4, 2018

Mark a few css-fonts tests as crashing
These are hitting a NOTREACHED() and blocking WPT imports after
web-platform-tests/wpt#9373 landed upstream.

TBR=foolip

Bug: 828748
Change-Id: I72ec5dbe80bd9f5e893a56380acd99aa62a91da0
No-Try: True
Reviewed-on: https://chromium-review.googlesource.com/995094
Reviewed-by: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Commit-Queue: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Cr-Commit-Position: refs/heads/master@{#548006}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.