Update: It looks like this rule broke the font rendering in 67:

`font: 700 100% 118px/118px "ProximaNova Extrabold"; font-kerning: auto;`

We removed `100%` and then the text rendered as expected. Here's the updated rule:

`font: 700 118px/118px "ProximaNova Extrabold"; font-kerning: auto;`

So it sounds like one of these may happened:
- Something about the `font` rule itself changed in 67
- The code that generates this rule/generated the 'inline' version of fonts changed
- Something in SVG rendering or canvas drawing changed

We did notice that the generated font styles definitely did change in 67. The new style was much larger (~100KB larger), and included things like ` unicode-range: U+0-FF, U+131, U+152-153, U+2BB-2BC, U+2C6, U+2DA, U+2DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;`, when those weren't included before.

Comment from a team member:

"It's the font-stretch property (defaulting to 100%) that it's trying to insert into the font property btw

(not the text-size-adjust)
It's clearly indicated on MDN that you cannot have both font-weight and font-stretch in a font style, but Chrome is trying to."

More conversation:

"sean: so Chrome generates this?
dave: Yeah this is the CSSRule magic stuff going on.
I think it's coming from CSSRule.cssText ultimately."

Sounds like this may have been caused by  issue 827921 .

I see what's going on. Per https://drafts.csswg.org/css-fonts-4/#font-prop:

Values for the font-stretch property can also be included but only those supported in CSS Fonts level 3, none of the font-stretch values added in this specification can be used in the font shorthand

We're serializing font-stretch percentages (defined in Fonts 4) in the font shorthand, creating a rule that cannot be reparsed.

Thank you so much. We have a workaround for now, but will be very happy when this is released.

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

commit 43f06f172201a5435d4106c9b8317e734e257aee
Author: Chris Nardi <cnardi@chromium.org>
Date: Tue Jun 19 09:51:43 2018

Serialize font-stretch values correctly in the font shorthand

Per the CSS Fonts 4 spec [1], only keyword values for font-stretch are
valid in the font shorthand. Our current serialization code ignores
this, and outputs percentage values as well in the shorthand, meaning
that the generated rule cannot be reparsed. We now check if the
percentage can be converted to a keyword, and if so, output it as that
keyword. Otherwise, we do not output a serialization for the font
shorthand, as per the CSSOM spec [2].

[1]: https://drafts.csswg.org/css-fonts-4/#font-prop
[2]: https://drafts.csswg.org/cssom/#serializing-css-values

Bug:  850092 
Change-Id: I7e3eec64723966b15abfa819213b95cba6cbc3d5
Reviewed-on: https://chromium-review.googlesource.com/1103856
Commit-Queue: Dominik Röttsches <drott@chromium.org>
Reviewed-by: Dominik Röttsches <drott@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568383}
[add] https://crrev.com/43f06f172201a5435d4106c9b8317e734e257aee/third_party/WebKit/LayoutTests/external/wpt/css/css-fonts/font-shorthand-serialization-font-stretch.html
[modify] https://crrev.com/43f06f172201a5435d4106c9b8317e734e257aee/third_party/blink/renderer/core/css/style_property_serializer.cc
[modify] https://crrev.com/43f06f172201a5435d4106c9b8317e734e257aee/third_party/blink/renderer/core/css/style_property_serializer.h

I saw that y'all made this changed, reviewed it, and merged it into 'master'. Thank you so much for your very fast work on this. We feel very heard and I personally have a lot of respect for you all -- you've been very receptive and helpful in all my interactions with you.

I'm glad you're happy with the speed of change, only sorry I didn't notice this bug in my original change! The fix should be in the next canary build, released tomorrow. I'm not sure that this change meets the bar for merging to M68, so the fix should be in M69.