1885414 - investors.twilio.com gives Firefox-on-macOS a broken "Whitney SSm A" font, via its fonts.css stylesheet that loads good/bad versions depending on UA string

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect, P3)

Description

[Sam Johnson]

Attachment: Example webpage displaying issue

Visit https://investors.twilio.com/news/news-details/2024/Twilio-Announces-Fourth-Quarter-and-Full-Year-2023-Results/default.aspx and note the display of the article text. Some characters, such as 's' and numbers, are displayed using Helvetica instead of the same font as other characters. The webpage is specifying the "Whitney SSm A" font.

Safari does not exhibit this issue; the article renders with a consistent font.

Comment 1

[Daniel Holbert [:dholbert]]

Interesting! I can reproduce on macOS with Firefox Nightly 125.0a1, as well as current release.

If I highlight e.g. the element

<span id="_ctrl0_ctl48_spanNewsDetailsTitle">Twilio Announces Fourth Quarter and Full Year 2023 Results</span>

...then the DevTools Fonts pane does indeed confirm that both "Whitney SSm A" and Helvetica are both being used to render that element.

On Ubuntu, DevTools reports that element just being rendered with `"Whitney SSm A" and no other fonts.

Comment 2

[Daniel Holbert [:dholbert]]

The site seems to be sending Firefox-on-macOS a different set of CSS styles. If I use Firefox with a Safari UA string, the site looks just fine.

I also created a reduced testcase using the @font-face styles that I got in a "broken" page load, and it looks broken everywhere (Safari, Chrome, Friefox-on-mac-and-Ubuntu). Essentially, the font seems to be missing some glyphs, and so we use whatever fallback font is specified to fill those in).

And if I use the @font-face styles from a "working" page-load instead, then the font has all of the correct glyphs and nothing is missing.

Comment 3

[Daniel Holbert [:dholbert]]

So specifically this stylesheet URL gives me a different 302 redirect target, depending on whether I use a Firefox-for-macOS UA string or not:

https://cloud.typography.com/6230892/752864/css/fonts.css

Firefox Nightly 125 on Ubuntu (configured regularly) gets redirected to this URL:
https://d3hjue7omxs01q.cloudfront.net/global/fonts/780758/3306E19801744AB42.css

whereas if I use that same browser but spoof a macOS UA string, I get redirected to this URL and I can see that the fonts are visibly different (as in the attached screenshot):
https://d3hjue7omxs01q.cloudfront.net/global/fonts/780758/D799964A456D3ED25.css

And these stylesheets have different content, with the latter one apparently having the font with the missing characters.

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (with A-Z a-z 0-9, explicitly referencing the stylesheet with broken fonts that the server gives to browsers with a Firefox-on-macOS UA string)

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: reference case 1 (same as testcase, but using the working stylesheet that the server gives to browsers with other UA strings)

Comment 6

[Daniel Holbert [:dholbert]]

Since this seems to be an issue with UA-string-specific redirects happening at https://cloud.typography.com, I sent an email to the support@ email address that I found on their website to notify them of the issue. Hopefully they can fix the redirect soon -- I'll update this bug report once I've heard back.

Comment 7

[Jonathan Kew [:jfkthame]]

Yeah, this is a site authoring bug. The issue happens because the version of the fonts.css stylesheet that they serve to Firefox splits each font into a pair of resources with "A" and "B" suffixes, e.g.

@font-face {
  font-family: "Whitney SSm A";
  src: url(data:application/x-font-woff2;base64,d09GMk9U....ggVB8A);
  font-weight:400;
  font-style:normal;
}
@font-face {
  font-family: "Whitney SSm B";
  src: url(data:application/x-font-woff2;base64,d09GMk9U....AKAAA=);
  font-weight:400;
  font-style:normal;
}

where each resource includes only a subset of the characters. The idea is that content should then use font-family: "Whitney SSm A", "Whitney SSm B" to request both fonts, and the browser will take characters from each as required. (This is an old "make it harder to extract a usable standalone font" trick that shows up from time to time.)

And indeed, their default styles in global.css include

body {
    font-family: Whitney SSm A,Whitney SSm B,Helvetica Neue,Helvetica,Arial,sans-serif;
}

which would've worked ok if it were left alone. But unfortunately this gets overridden by rules that use a bunch of custom properties defined in GlobalBranding.ashx, such as

--evgBodyFontFamily: "Whitney SSm A", Helvetica, Arial, sans-serif;

and lots of others for different element types. These rules only mention the "A" subset of the font. And so whatever characters were supposed to come from the "B" face will fall back to Helvetica or Arial instead.

For some reason, other browsers (I tried in Safari) get a different version of the fonts.css resource where this "splitting" of the fonts is not present, and the entire font is provided as a unified "Whitney SSm A" face. Why do they serve different these font stylesheets depending on the browser? No idea...

Comment 8

[Thomas Wisniewski [:twisniewski]]

I don't know why this has the sitepatch-applied keyword, as there isn't actually any such site-patch, and I don't see it having ever existed.

I also think this issue may be fixed by the site now. The URL to the page has since changed (I've updated it on the bug), and that text is bold when I visit it now on my MacBook. Jonathan, would you mind confirming whether that's true? Perhaps I'm missing some nuance.

Comment 9

[Sam Johnson]

I can confirm that the site has changed and no longer has the problem.

Comment 10

[Daniel Holbert [:dholbert]]

Thanks! Let's just close this out then. Maybe my outreach in comment 6 had an effect, or maybe they just redesigned the site and happened to remove the troublesome parts. :)

(Closing as "worksforme" rather than "fixed" since we're not entirely sure how/why it became fixed.)

Comment 11

[Jonathan Kew [:jfkthame]]

Yeah, the site has changed and it's now using the default system font for most of the content. They do still have their problematic webfont, split across two family names "Whitney SSm A" and "Whitney SSm B", but it's only being used for a bit of header & footer stuff, and I'm not seeing the issue where another style rule is overriding font-family and only specifying one of the parts of the split font.

So yes, the site now seems to be ok, though I suspect it may be more "by chance" as a side-effect of their decision to change their main body font to system-ui, rather than a conscious "fixing" of the original bug.