Closed Bug 1419848 Opened 3 years ago Closed 5 months ago

webfont loading with <link rel=preload ...> appears not to work on https://clearleft.com/

Categories

(Core :: DOM: Core & HTML, defect, P2)

defect

Tracking

()

RESOLVED DUPLICATE of bug 1626997
Webcompat Priority -
Tracking Status
firefox59 --- affected

People

(Reporter: jfkthame, Unassigned)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [wecompat])

Email from Jet:

> I'm seeing FOUT on https://clearleft.com/ that seems to indicate that stylesheets are loaded but fonts are not. Looks OK on Chromium.

I can confirm that I see FOUT on this site (when it's not already in cache). Offhand, I don't see anything about the preload links on the page that should prevent them working. Dragana, can you take a look?

(Possibly unrelated, but I can't tell any difference in behavior whether network.preload is set to 'true' or 'false'. Does that pref actually have any effect?)
Interestingly, if I set layout.css.servo.enabled to 'false', the FOUT no longer occurs. Does this mean that switching to stylo is somehow regressing <link rel=preload> behavior? (Or does it mean that with stylo, we're now styling the content so fast that the fonts haven't yet loaded despite the preload request?)

Looking at the Network tab in developer tools, it appears that the requests for the (supposedly preloaded) fonts are ending up behind a lot of images used by the page; is this the expected behavior, or should those early <link rel=preload> requests be given higher priority?
Preload is disabled.

I do not much about stylo code. Is it not properly disabled when stylo is used?

Preload should not influence page load except if there is a something listening for 'onload' events from <link rel=preload> element. Something like bug  1405761. Bug  1405761 will appear only if preload is not properly disabled with stylo. But bug  1405761 does not appear again with stylo. so here we have another problem.

What is 'FOUT' where I can see it?
Sorry, "FOUT" is jargon for "flash of unstyled text", meaning that the content appears for a moment with a fallback font, before the webfont is available and it gets repainted with the intended font.

(This only happens on the https://clearleft.com/ site when it is loaded with the cache empty; on normal reloading, or returning after having visited it recently, the font files are cached and the flash doesn't happen.)

The site is using

    <link rel="preload" as="font" type="font/woff2" href="/assets/fonts/adellesans-regular-webfont.woff2" crossorigin>
    <link rel="preload" as="font" type="font/woff2" href="/assets/fonts/gilroy-black-webfont.woff2" crossorigin>

to try and avoid this, by asking the browser to load the font resources early, so that they'll be ready by the time the initial paint happens.
(In reply to Dragana Damjanovic [:dragana] from comment #2)
> Preload is disabled.

I see that network.preload is false by default; if I toggle it to true, should that make preload start working, or is something else required? I don't see any difference in behavior, AFAICT. Or is that pref not related to <link rel=preload> handling?
(In reply to Jonathan Kew (:jfkthame) from comment #4)
> (In reply to Dragana Damjanovic [:dragana] from comment #2)
> > Preload is disabled.
> 
> I see that network.preload is false by default; if I toggle it to true,
> should that make preload start working, or is something else required? I
> don't see any difference in behavior, AFAICT. Or is that pref not related to
> <link rel=preload> handling?

the pref should turn  <link rel=preload> on, but it is disabled for a couple of reasons (bug 1394778 - for no-cachable resources it will not work (I think I have seen that this resources are cacheable, so this is not the problem here) and bug 1393540 (this is maybe problem here that speculative load is triggered before preload, i.g. images are fetched earlier. Because of this bug I think we will implement preload in a different way.)). 

Is it working better with servo=false preload=true than (servo=false preload=false) or (servo=true preload=false/true)?
Priority: -- → P2
Flags: webcompat?
Whiteboard: [wecompat]
Flags: webcompat? → webcompat-

See bug 1547409. Moving webcompat whiteboard tags to project flags.

Webcompat Priority: --- → -
See Also: → 1500646
No longer blocks: 1222633
Depends on: 1600117, 1222633

Hi, Just dropping here other example: https://bac.hotsoft.com.br/
I'm using preload and other link tricks.

The load process is very different than the other browser engines.

Thanks!

I believe this will be fixed with enabling network.preload by default now, on Nightly; modulo bug 1637671.

(In reply to Wellington Torrejais da Silva from comment #7)

Hi, Just dropping here other example: https://bac.hotsoft.com.br/
I'm using preload and other link tricks.

The load process is very different than the other browser engines.

Thanks!

It's been 4 months; I can't see any major difference in how Chrome and Firefox Nightly (both with and without preload) renders the site. More specific explanation of unexpected symptoms would help. I don't FOUT.

This can likely be duplicated to bug 1626997.

Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1626997
You need to log in before you can comment on or make changes to this bug.