Web-bugs: developer.mozilla.org - Headings not using webfonts

[yoasif]

URL: https://developer.mozilla.org/en-US/docs/Web/CSS/appearance

Browser / Version: Firefox 66.0
Operating System: Linux
Tested Another Browser: Yes

Problem type: Design is broken
Description: Headings not using webfonts
Steps to Reproduce:
Headings like:

appearance (-moz-appearance, -webkit-appearance)
Syntax
Examples
Specifications

are not using web fonts.

They appear correctly in Chromium.

Browser Configuration

• mixed active content blocked: false
• image.mem.shared: true
• buildID: 20181211093801
• tracking content blocked: false
• gfx.webrender.blob-images: true
• hasTouchScreen: false
• mixed passive content blocked: false
• gfx.webrender.enabled: false
• gfx.webrender.all: true
• channel: nightly

Console Messages:

[u'[JavaScript Error: "downloadable font: download timed out (font-family: "zillaslab" style:normal weight:700 stretch:100 src index:0) source: https://developer.mozilla.org/static/fonts/locales/ZillaSlab-Bold.subset.e96c15f68c68.woff2" {file: "unknown" line: 1 column: 276 source: "@font-face {\n  font-family: zillaslab;\n  src: url("../../fonts/locales/ZillaSlab-Bold.subset.e96c15f68c68.woff2") format("woff2"), url("../../fonts/locales/ZillaSlab-Bold.subset.da0ccde4ca4a.woff") format("woff");\n  font-style: normal;\n  font-weight: 700;\n  font-display: optional;\n}"}]']

_From webcompat.com with ❤️_

[softvision-oana-arbuzov]

Thanks for the report @yoasif , I was able to reproduce the issue.

Tested with:
Browser / Version: Firefox Nightly 66.0a1 (2018-12-12)
Operating System: Linux Ubuntu 16.04

Moving to Needsdiagnosis for further investigation.

[reinhart1010]

I can also reproduce this on Firefox Developer Edition 65. From the Fonts tab on devtools, it seems that the "Zilla Slab" font is also downloaded during the load of page.

It seems that the font-display CSS settings matters at all. Here's from https://developer.mozilla.org/static/build/styles/locale-en-US.520ecdcaef8c.css

@font-face {
 font-family:zillaslab;
 font-display:fallback;
 src:url("../../fonts/locales/ZillaSlab-Regular.subset.bbc33fb47cf6.woff2") format("woff2"),
 url("../../fonts/locales/ZillaSlab-Regular.subset.0357f12613a7.woff") format("woff");
 font-weight:400;
 font-style:normal
}
@font-face {
 font-family:zillaslab;
 font-display:optional;
 src:url("../../fonts/locales/ZillaSlab-Bold.subset.e96c15f68c68.woff2") format("woff2"),
 url("../../fonts/locales/ZillaSlab-Bold.subset.da0ccde4ca4a.woff") format("woff");
 font-weight:700;
 font-style:normal
}

Other browsers (tested: Chrome, EdgeHTML) can still render the page completely. Maybe there is a rendering issue in Firefox.

[csnover]

Per the spec, font-display: fallback and font-display: optional mean that the browser will fail the webfonts and not use them at all once the block and swap periods have expired, instead of allowing the fonts to be rendered any time they become available in the future.

Gecko uses the gfx.downloadable_fonts.fallback_delay_short preference for the block time, and gfx.downloadable_fonts.fallback_delay for the font-display: fallback swap time. (The swap time for font-display: optional is always 0.) The default values are the same as the ones recommended in the spec, so for font-display: optional this means that if the font isn’t fully loaded in 100ms, then it will never be rendered, and for font-display: fallback if the font isn’t loaded in 3000ms then it will never be rendered.

On this page, something like this is happening:

1. The browser parses the markup for the page and starts downloading resources immediately as they are encountered in markup. On this page this means hundreds of requests because there around 160 inline frames;
2. The CSS file finishes downloading and is parsed so the browser becomes aware of the @font-face usage;
3. The browser queues the network download for the font, which starts the font download timer;
4. The font downloads are blocked by all of the downloads for the ~160 inline frames which were already queued during HTML parsing;
5. The web fonts can finally be downloaded but it’s already taken >100ms to flush the queue of all the inline frame resources so the header fonts are guaranteed to not render due to font-display: optional;
6. If you’re lucky and have a fast connection, the non-header zillaslab font will render if you downloaded all the inline frames and the web fonts in under 3 seconds, otherwise that one fails too.

Looking at the network traces in Chrome versus Firefox it looks like the difference is that Chrome rearranges the network request queue so that the resources from CSS get a higher priority than the inline frames, even though they aren’t discovered until after the inline frame resources. This means the WOFF file gets downloaded straight away, instead of in Gecko where all the inline frames must download first. This would be a good UX performance optimisation for Gecko but I’m not sure that it’s actually a site or a browser bug, rather just an unfortunate use of font-display on a page with a ridiculous number of inline frames. (Though I am not totally sure of this since it seems like Gecko tries to set the priority of the requests, so maybe the priority setting is actually broken?) If you visit this page after another page so that the web fonts are already cached locally, then Firefox will render the headers correctly since it doesn’t need to wait for the network.

[karlcow]

@emilio @jfkthame what would you recommend we do here? Apart of the MDN issue in itself. Do you think it's worth trying to optimize Gecko for this case?

Thanks a lot for the detailed analysis @csnover super useful.

[jfkthame]

On this page, something like this is happening:

1. The browser parses the markup for the page and starts downloading resources immediately as they are encountered in markup. On this page this means hundreds of requests because there around 160 inline frames;

2. The CSS file finishes downloading and is parsed so the browser becomes aware of the `@font-face` usage;

3. The browser queues the network download for the font, which starts the [font download timer](https://drafts.csswg.org/css-fonts-4/#font-display-timeline);

A small adjustment to the sequence described here: the browser doesn't queue a request for the font when it parses the CSS and finds the @font-face rule, because at that point it doesn't know whether the font will actually be required. Font downloads are only requested when text-run construction (usually during reflow) occurs and the font matching algorithm determines that a particular resource is needed.

(The CSS Font Loading API can be used to proactively initiate downloads, independently of trying to actually reflow content that requires a given font; one "fix" for the page would probably be to explicitly load the desired font via a script that runs early in loading.)

(Though I am not totally sure of this since it seems like Gecko tries to set the priority of the requests, so maybe the priority setting is actually broken?)

Might be worth asking someone from the Networking side about the behavior here.

[emilio]

So, I'm not much of a networking guy, but this seems worth tracking on bugzilla to me.

Gecko will wait until it knows the font will be used in order to kick of the load. It may be the case that Blink's preloader does something smart for fonts? @yoavweiss may know about this. I don't know if I'd consider that a bug or a feature, given the font-display descriptor value, but in any case it'd be good to be interoperable here.

[yoavweiss]

Blink's preloader doesn't do anything smart about fonts, but it does detect <link rel preload> which is what makes the font download significantly earlier/faster in this case.
So in order to catch up here, Firefox will need to ship preload support (which I believe is implemented but not yet shipped).

[wisniewskit]

Based on the above comments, it sounds to me like this is essentially a dupe of bz1419848 (blocked on link preloading support). @karlcow, what do you think?

[karlcow]

Close as duplicate of #1419848 (Mozilla)

[lock[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue at https://webcompat.com/issues/new if you are experiencing a similar problem.