Regressed on Windows, too.

Attaching some screenshots.

Deleted: Screen Shot 2017-11-03 at 11.46.07 AM.png 804 KB

	Screen Shot 2017-11-03 at 11.46.07 AM.png 804 KB View Download

Deleted: Screen Shot 2017-11-03 at 11.46.33 AM.png 886 KB

	Screen Shot 2017-11-03 at 11.46.33 AM.png 886 KB View Download

Deleted: Screen Shot 2017-11-03 at 11.47.05 AM.png 993 KB

	Screen Shot 2017-11-03 at 11.47.05 AM.png 993 KB View Download

You are probably looking for a change made after 505401 (known good), but no later than 505423 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/549c7f97a47bc11f7cbc4d023bf96dd40d2f53c6..1b3182253006df2ca3297a5182da86627cfd37b0

The only plausible CL is 126dc76bd00c11209ccf65ea151d5263fde0c7dc which has to do with fonts. Assigning.

This will almost certainly need a merge when fixed.

This is indeed a regression by 126dc76bd00c11209ccf65ea151d5263fde0c7dc.

It's an interesting corner case. The site has a @font-face rule like this:

@font-face {
    font-family: 'FontAwesome';
    src: url("//xxx.cloudfront.net/fontawesome.woff2") format("woff2"),
         url("//xxx.cloudfront.net/fontawesome.woff") format("woff");
}

CloudFront is configured to add "Access-Control-Allow-Origin:*" response header for the woff file, but not for the woff2 file. Chrome first requests fontawesome.woff2, but the request is *cancelled* due to CORS violation. After 126dc76bd00c11209ccf65ea151d5263fde0c7dc, Chrome doesn't fallback to next url().

It seems 126dc76bd00c11209ccf65ea151d5263fde0c7dc didn't fix bug 763040, so probably we should just revert it?

I don't know enough about this to say yes, but if there's a change that breaks the web and wasn't actually a fix to a problem, then yes?

I have a fix for a similar bug at https://chromium-review.googlesource.com/c/chromium/src/+/749672, but I'm worried it won't catch this case. 126dc76bd00c11209ccf65ea151d5263fde0c7dc did fix a real bug (where font fallback triggering during window.stop() wouldn't properly stop the font fallback), but it's not as easily observable from the web platform. So I'm ok with reverting to make sure that issue gets fixed the right way.

Nate, can you do so then?

This revert/merge is going to be a pain, because master has conflicts, but it doesn't look like the M63 branch does. But yeah, I can.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d8bfda2014e0a78237cc57de958898a6594faf29

commit d8bfda2014e0a78237cc57de958898a6594faf29
Author: Nate Chapin <japhet@chromium.org>
Date: Mon Nov 06 20:14:46 2017

Revert "If a font resource load is cancelled, don't fallback to a different font."

Some cases are flagged as cancellations that aren't exactly, and that we want
to fall back after.

This reverts commit 126dc76bd00c11209ccf65ea151d5263fde0c7dc.

TBR=toyoshim

Bug:  780389 ,  781270 
Change-Id: Ib8d6f96e63c1cd9b87e87c8651b7fdbafa69e460
Reviewed-on: https://chromium-review.googlesource.com/755316
Reviewed-by: Nate Chapin <japhet@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Nate Chapin <japhet@chromium.org>
Cr-Commit-Position: refs/heads/master@{#514226}
[modify] https://crrev.com/d8bfda2014e0a78237cc57de958898a6594faf29/third_party/WebKit/Source/core/css/CSSFontFace.cpp
[modify] https://crrev.com/d8bfda2014e0a78237cc57de958898a6594faf29/third_party/WebKit/Source/core/css/CSSFontFace.h
[modify] https://crrev.com/d8bfda2014e0a78237cc57de958898a6594faf29/third_party/WebKit/Source/core/css/RemoteFontFaceSource.cpp

Verified the issue on windows 10 and Mac OS 10.12.6 using chrome M64 #64.0.3261.0 and issue seems fixed.

The icon fonts are shown as expected. Attached screencast for reference.

Adding TE-Verified Labels.

Thanks!

Deleted: 781270.mp4 1.3 MB

	781270.mp4 1.3 MB View Download

This will need some merge to 63.

Yep, merge already requested on the other bug mentioned in the revert description (780389)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/994d3c17a0623dcfdfb563e1db7640f10bb2ecc9

commit 994d3c17a0623dcfdfb563e1db7640f10bb2ecc9
Author: Nate Chapin <japhet@chromium.org>
Date: Fri Nov 10 19:58:43 2017

Revert "If a font resource load is cancelled, don't fallback to a different font."

Some cases are flagged as cancellations that aren't exactly, and that we want
to fall back after.

This reverts commit 126dc76bd00c11209ccf65ea151d5263fde0c7dc.

TBR=japhet@chromium.org, toyoshim

(cherry picked from commit d8bfda2014e0a78237cc57de958898a6594faf29)

Bug:  780389 ,  781270 
Change-Id: Ib8d6f96e63c1cd9b87e87c8651b7fdbafa69e460
Reviewed-on: https://chromium-review.googlesource.com/755316
Reviewed-by: Nate Chapin <japhet@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Nate Chapin <japhet@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#514226}
Reviewed-on: https://chromium-review.googlesource.com/764371
Cr-Commit-Position: refs/branch-heads/3239@{#442}
Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578}
[modify] https://crrev.com/994d3c17a0623dcfdfb563e1db7640f10bb2ecc9/third_party/WebKit/Source/core/css/CSSFontFace.cpp
[modify] https://crrev.com/994d3c17a0623dcfdfb563e1db7640f10bb2ecc9/third_party/WebKit/Source/core/css/CSSFontFace.h
[modify] https://crrev.com/994d3c17a0623dcfdfb563e1db7640f10bb2ecc9/third_party/WebKit/Source/core/css/RemoteFontFaceSource.cpp

Verified the issue on windows 10 and Mac OS 10.12.6 using chrome M63 #63.0.3239.52 and issue seems fixed.

The icon fonts are shown as expected. Attached screencast for reference.

Hence adding TE-Verified Labels.

Thanks!

Deleted: 781270.mp4 2.2 MB

	781270.mp4 2.2 MB View Download