Seems to be a problem specific to the shorthand ('font') parsing. The longhand seems to DTRT.

Checked the issue on reported chrome version  67.0.3377.0 and on the latest stable 65.0.3325.181 using Windows 10, Ubuntu 14.04 and Mac 10.13.1. 

We are able to see "2024 Pass" which is reported as wrong behaviour.
                    208 Fail  

And we didn't observe any "2322 Pass" results after navigating to the given URL and searching for "Fail".

As this similar behaviour is seen from M60(60.0.3072.0) considering it as Non-Regression.

Thanks!

I don't understand the tests here, how does font: '16px simple, initial bongo' parse? I don't think that CSS-wide keywords work in lists.

(typo, I meant 'font: 16px simple, initial bongo')

@timloh you are right, it is not very clear. The only idea I have why "simple, initial bongo" qualifies as font-family is this:
"If a sequence of identifiers is given as a font family name, the computed value is the name converted to a string by joining all the identifiers in the sequence by single spaces."
https://drafts.csswg.org/css-fonts-4/#font-family-prop

I think that is correct. 

However, if you find parts of tests that you think are incorrect, please report them by raising an issue:
https://github.com/w3c/web-platform-tests/labels/wg-css
and we will fix them. 

Likewise, if the spec is wrong, contradictory or unclear then please raise an issue:
https://github.com/w3c/csswg-drafts/labels/css-fonts-3
and we will discuss, and fix the spec.

> I don't understand the tests here, how does font: '16px simple, initial bongo' parse? I don't think that CSS-wide keywords work in lists.


Exactly. The test is to make sure that things which look like CSS-wide keywords are *not* treated specially in font family names.

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

commit 2d5bb27c5c0d59fbb8f7a961b5d6861480f154f1
Author: Rob Buis <rob.buis@samsung.com>
Date: Tue Apr 03 12:26:57 2018

Make font shorthand initial/inherit parsing less strict

Make font shorthand initial/inherit parsing less strict, the
current solution means the special logic in ConsumeFontFamily
is not taken into account. Since all font longhands will reject
css wide keywords and ConsumeFontFamily has special rules for them,
we can just remove the while loop.

Bug:  824611 

Change-Id: I9bae2c1497e61bb0d93973bb1bfaac386d0c6d0b
Reviewed-on: https://chromium-review.googlesource.com/982557
Reviewed-by: Timothy Loh <timloh@chromium.org>
Commit-Queue: Rob Buis <rob.buis@samsung.com>
Cr-Commit-Position: refs/heads/master@{#547677}
[delete] https://crrev.com/0e8b553a69ead6ff3cbf96e61358335bddc94f67/third_party/WebKit/LayoutTests/external/wpt/css/css-fonts/test_font_family_parsing-expected.txt
[modify] https://crrev.com/2d5bb27c5c0d59fbb8f7a961b5d6861480f154f1/third_party/WebKit/LayoutTests/fast/css/font-shorthand-mix-inherit-expected.txt
[modify] https://crrev.com/2d5bb27c5c0d59fbb8f7a961b5d6861480f154f1/third_party/WebKit/LayoutTests/fast/css/font-shorthand-mix-inherit.html
[modify] https://crrev.com/2d5bb27c5c0d59fbb8f7a961b5d6861480f154f1/third_party/WebKit/Source/core/css/properties/shorthands/FontCustom.cpp