Opened 6 years ago

Closed 6 years ago

#8455 closed project (fixed)

Limit @font-face font local() fonts and disable local fallback rendering

Reported by: mikeperry Owned by: mikeperry
Priority: Very High Milestone:
Component: Firefox Patch Issues Version:
Severity: Keywords: tbb-fingerprinting, tbb-rebase-regression, MikePerry201304
Cc: gk Actual Points: 6
Parent ID: Points:
Reviewer: Sponsor:


Gk pointed out in that the initial display font before the WebFont is loaded is the "best fallback CSS font on the user's computer" (from

My guess was that the chosen font will be the default system font for the specified style if we don't have that font family, but what if the WebFont has the same name as a font that is on the system? Do we exempt it and allow text to be rendered with that local font briefly? Or does Firefox decide not to download the WebFont in the first place, such that that rule will count as a font probe?

Child Tickets

Change History (9)

comment:1 Changed 6 years ago by mikeperry

Summary: Test font exempt font fallback rendering behaviorTest initial remote font fallback rendering behavior

comment:2 Changed 6 years ago by mikeperry

Keywords: tbb-rebase-regression added

If this is true, it's a regression in the FF17-based series. Tagging it as such preemptively so we don't forget about it.

comment:3 Changed 6 years ago by mikeperry

Priority: majorcritical
Summary: Test initial remote font fallback rendering behaviorFix @font-face font fallback rendering behavior

Turns out you can specify an explicit local fallback that does in fact work just fine. gacar posted this url to #8270 that uses this mechanism to probe for fonts..

comment:4 Changed 6 years ago by mikeperry

Keywords: MikePerry201304 added

comment:5 Changed 6 years ago by mikeperry

ok, the local() font probe code is in gfxUserFontSet::LoadNext(). It's pretty easy to make it prefer url() over local(), but I'm not sure what the behavior should be if there is no URL specified. Do we expect this behavior to be rare? Should we just fail those fonts entirely?

The main problem is that we don't have direct access to the pres shell from there to update out font counts. Some black magic subclass access to nsUserFontSet might give us access, but that might be fragile..

This is also a different piece of code from the "best temporary fallback" behavior gk found. I'm not sure where that lives yet.

comment:6 Changed 6 years ago by mikeperry

gfx.downloadable_fonts.fallback_delay governs how long until fallbacks are used. Unfortunately no values of that pref fully disable the behavior (see nsFontFaceLoader::StartedLoading()).

It looks like the fallback might be governed by callers of gfxUserFontSet::FindFontEntry(). Two possiblitities for further investigation are gfxFontGroup::FindPlatformFont() and gfxFontGroup::ForEachFontInternal() and their subsequnt calls to gfxPlatform::ResolveFontName() and gfxPlatformFontList::FindFontForFamily(). Both set gfxFontGroup->mSkipDrawing if it's not yet time to use the fallback font... The bad news is it looks like you can still compute the width of the fallback font even before it is actually drawn (see gfxTextRun::Draw()).

comment:7 Changed 6 years ago by mikeperry

If we're lucky, fixing/improving/eliminating the fallback behavior may also solve #8633.

comment:8 Changed 6 years ago by mikeperry

Status: newneeds_review

I merged an update to the font patch that should fix the local() issue to maint-2.4. The patch also "disables" fallback if you set gfx.downloadable_fonts.fallback_delay to -1, but it may still be possible to infer text sizes from fonts before they actually render.

We should either figure out how to test that, or create a separate ticket for it. Setting this to needs review in the meantime.

comment:9 Changed 6 years ago by mikeperry

Actual Points: 6
Resolution: fixed
Status: needs_reviewclosed
Summary: Fix @font-face font fallback rendering behaviorLimit @font-face font local() fonts and disable local fallback rendering

Ok, I am going to declare this fixed since the patch is in origin/maint-2.4 now and it works for me against that jsfiddle link, but sadly it did not appear to fix #8633. I saw an instance of #8633 (or something closely related) again in my debug build.

Also, I filed #8770 to remind us to verify there are no race conditions or ways to probe local fonts using @font-face before fonts finish downloading.

Note: See TracTickets for help on using tickets.