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

Gk pointed out in https://trac.torproject.org/projects/tor/ticket/5273#comment:42 that the initial display font before the WebFont is loaded is the "best fallback CSS font on the user's computer" (from https://developer.mozilla.org/en-US/docs/CSS/@font-face).

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?

added MikePerry201304 actualpoints::6 component::firefox patch issues owner::mikeperry priority::very high resolution::fixed status::closed tbb-fingerprinting tbb-rebase-regression type::project labels

Trac:
Summary: Test font exempt font fallback rendering behavior to Test initial remote font fallback rendering behavior

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.

Trac:
Keywords: N/A deleted, tbb-rebase-regression added

Turns out you can specify an explicit local fallback that does in fact work just fine. gacar posted this url http://jsfiddle.net/C4t7w/13/ to #8270 (closed) that uses this mechanism to probe for fonts..

Trac:
Priority: major to critical
Summary: Test initial remote font fallback rendering behavior to Fix @font-face font fallback rendering behavior

Trac:
Keywords: N/A deleted, MikePerry201304 added

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.

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()).

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

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.

Trac:
Status: new to needs_review

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 (moved). I saw an instance of #8633 (moved) (or something closely related) again in my debug build.

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

Trac:
Resolution: N/A to fixed
Summary: Fix @font-face font fallback rendering behavior to Limit @font-face font local() fonts and disable local fallback rendering
Actualpoints: N/A to 6
Status: needs_review to closed

closed

added 48h of time spent

mentioned in issue #8633 (moved)

mentioned in issue #8770 (moved)

mentioned in issue #8939 (closed)

mentioned in issue #9018 (moved)

mentioned in issue #27258 (moved)

mentioned in issue tpo/applications/tor-browser#8770 (closed)

mentioned in issue tpo/applications/tor-browser#9018 (closed)