1331797 - Can't load fonts on https://fonts.google.com/

Status: RESOLVED FIXED

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

Description

[Juan José Rubio]

Attachment: bugs.png

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170117004014

Steps to reproduce:

Can't load google fonts

Comment 1

[Loic]

Reg range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2387ada864282880d3a498d643abe3d8b887ee59&tochange=e193b4da0a8c1025aa76a403c64663ff1cd41709

I'm not able to reproduce the issue with FF50/51, but only with FF52/53 so it looks like a feature enabled by default in nightlies triggers this bug.
In addition, some old nightlies are affected too.

Comment 2

[Jonathan Kew [:jfkthame]]

See bug 1193050 and bug 1244693. Nightly and Aurora builds apply stricter font validation which may cause some (out-of-spec) fonts to be rejected, but on release channels we allow them to load, so that users in general are not affected.

Comment 3

[Kohei Yoshino [:kohei]]

I've just noticed this. Added a note on my site compatibility doc:

https://www.fxsitecompat.com/en-CA/docs/2016/some-web-fonts-may-not-be-displayed-due-to-stricter-validation/

Comment 4

[Mats Palmgren (inactive)]

The "broken" fonts seems to work fine in Nightly/Linux when I type in their editable
area though.  So this might be some script related issue on the page rather than
the font not working?  Maybe the page isn't waiting for the font file to load?

Comment 6

[Jonathan Kew [:jfkthame]]

(In reply to Mats Palmgren (:mats) from comment #4)
> The "broken" fonts seems to work fine in Nightly/Linux when I type in their
> editable
> area though.  So this might be some script related issue on the page rather
> than
> the font not working?  Maybe the page isn't waiting for the font file to
> load?

Interesting; could you give a specific example of a font where you're seeing this? Thanks.

Comment 7

[Mats Palmgren (inactive)]

For example, the very first one, Roboto.  It displays grey boxes,
but when I type in it the added text is definitely using the Roboto
font.  Same for the others.

(and I double-checked that gfx.downloadable_fonts.otl_validation
is indeed true)

The first few fonts that are "broken" for me are:
Roboto
Diplomata SC
Ranga
Roboto Condensed
Merriweather
Gidugu
...

They all seem to work when I type in them, except for Merriweather
which first displays the correct glyph, then 1/2 a second later
it's replaced with a grey box!

Also, when I scroll up to the start again, the Roboto and
Diplomata SC boxes where I added text is now displaying *all*
its text, not just the characters I typed, in the correct font.
I.e. they grey boxes that originally were there have now been
replaced with text in the correct font.

There's definitely something weird with the scripts on this page!

Comment 8

[Mats Palmgren (inactive)]

BTW, I see error messages from Angular for these fonts:
Native load test failed: Roboto  java/com/google/fonts/directory/ui/angular_js.js:119:50
etc

There are no font sanitizer error messages as far as I can tell.

Comment 9

[Jonathan Kew [:jfkthame]]

Did you check the browser console (not web console) for messages? Last I checked, the new web console UI wasn't showing them...

Comment 10

[Jonathan Kew [:jfkthame]]

And if you set gfx.downloadable_fonts.otl_validation to false, does that "fix" things?

Comment 11

[Jonathan Kew [:jfkthame]]

My guess: for the initial display, they serve a subsetted font that only includes the glyphs needed for the sample text, and that subset is broken. When you go to edit the text, they serve the complete font file (as you might type any arbitrary text in there), and that has valid OTL tables.

Comment 12

[Jonathan Kew [:jfkthame]]

cc'ing Dave at the Google Fonts team.

Comment 13

[Mats Palmgren (inactive)]

(In reply to Jonathan Kew (:jfkthame) from comment #9)
> Did you check the browser console (not web console) for messages? Last I
> checked, the new web console UI wasn't showing them...

Oh, I do see them in Browser Console:

downloadable font: Layout: DFLT script doesn't satisfy the spec. DefaultLangSys is NULL (font-family: "Roboto script=latin rev=1" style:normal weight:normal stretch:normal src index:0) source: https://fonts.gstatic.com/l/font?kit=R83x8tDq6bs7fGi-4KNwGDfoXgKNNy5HjCMcQpfQcXSlTkKTlyxIeV8tmWdfX_70&skey=a0a0114a1dcab3ac&v=v15  fonts.google.com:1:12
downloadable font: Layout: Failed to parse script table 0 (font-family: "Roboto script=latin rev=1" style:normal weight:normal stretch:normal src index:0) source: https://fonts.gstatic.com/l/font?kit=R83x8tDq6bs7fGi-4KNwGDfoXgKNNy5HjCMcQpfQcXSlTkKTlyxIeV8tmWdfX_70&skey=a0a0114a1dcab3ac&v=v15  fonts.google.com:1:12
downloadable font: GSUB: Failed to parse script list table (font-family: "Roboto script=latin rev=1" style:normal weight:normal stretch:normal src index:0) source: https://fonts.gstatic.com/l/font?kit=R83x8tDq6bs7fGi-4KNwGDfoXgKNNy5HjCMcQpfQcXSlTkKTlyxIeV8tmWdfX_70&skey=a0a0114a1dcab3ac&v=v15  fonts.google.com:1:12
downloadable font: rejected by sanitizer (font-family: "Roboto script=latin rev=1" style:normal weight:normal stretch:normal src index:0) source: https://fonts.gstatic.com/l/font?kit=R83x8tDq6bs7fGi-4KNwGDfoXgKNNy5HjCMcQpfQcXSlTkKTlyxIeV8tmWdfX_70&skey=a0a0114a1dcab3ac&v=v15


(Sigh. It's rather confusing to have two different consoles - these error messages
should be visible to web developers, which I suspect use Web Console.)

Comment 14

[Mats Palmgren (inactive)]

(In reply to Jonathan Kew (:jfkthame) from comment #10)
> And if you set gfx.downloadable_fonts.otl_validation to false, does that
> "fix" things?

Yup, turning off validation fixes the problem.

Comment 15

[timbugzilla]

I've started getting this recently with win x64 nightly builds. Does changing gfx.downloadable_fonts.otl_validation to false present any security risks?

http://www.thesilverfern.com/recent

Comment 18

[timbugzilla]

Does changing gfx.downloadable_fonts.otl_validation to false present any security risks?

Comment 19

[Jonathan Kew [:jfkthame]]

(In reply to timbugzilla from comment #18)
> Does changing gfx.downloadable_fonts.otl_validation to false present any
> security risks?

We're not currently aware of any, though it does bypass one layer of protection and so in principle it increases the chances that a flaw may be exposed.

(In theory, the harfbuzz library which is the eventual user of these tables has its own checking/sanitization process and will behave safely in the face of corrupt or malicious data. Of course, we can't guarantee that checking is 100% robust in every case, so applying a separate independently-implemented validation ahead of time provides added reassurance: a bad/malicious font would then have to be subtle enough to slip through -both- validation processes in order to cause mischief.)

Note that we're sufficiently comfortable with this that we ship release Firefox builds with the pref set to false, so that general users will not be affected by these out-of-spec fonts failing to load, as unfortunately they're rather widespread. The pref still defaults to true on developer builds in the hope that web authors will become aware of the issue and pressure their font suppliers to fix their resources.

Comment 20

[timbugzilla]

(In reply to Jonathan Kew (:jfkthame) from comment #19)
> (In reply to timbugzilla from comment #18)
> > Does changing gfx.downloadable_fonts.otl_validation to false present any
> > security risks?
> 
> We're not currently aware of any, though it does bypass one layer of
> protection and so in principle it increases the chances that a flaw may be
> exposed.
> 
> (In theory, the harfbuzz library which is the eventual user of these tables
> has its own checking/sanitization process and will behave safely in the face
> of corrupt or malicious data. Of course, we can't guarantee that checking is
> 100% robust in every case, so applying a separate independently-implemented
> validation ahead of time provides added reassurance: a bad/malicious font
> would then have to be subtle enough to slip through -both- validation
> processes in order to cause mischief.)
> 
> Note that we're sufficiently comfortable with this that we ship release
> Firefox builds with the pref set to false, so that general users will not be
> affected by these out-of-spec fonts failing to load, as unfortunately
> they're rather widespread. The pref still defaults to true on developer
> builds in the hope that web authors will become aware of the issue and
> pressure their font suppliers to fix their resources.

Thanks for the detailed response!

Comment 21

[Albert Scheiner [:alberts]]

Here is an issue over at google/fonts over on Github: https://github.com/google/fonts/issues/738

Comment 22

[arthur.lutz]

I thinks I'm getting this bug too. Am using FF53, but I did try out nightly at some point (probably with the same profile which is a bad idea). Setting gfx.downloadable_fonts.otl_validation to false doesn't fix it.

Comment 23

[arthur.lutz]

Can't seem to find a fix for this problem, I'm investigating on the addons side just in case, but I'm kind of stuck. I've switched back to nightly, let it upgrade, but the fonts still don't show.

Comment 24

[arthur.lutz]

Sorry for the noise, apt install fonts-roboto* fixes it for me. (or is it a different bug that firefox thinks the font is installed but doesn't detect that it isn't ?)

Comment 26

[Thomas Wisniewski]

The related Google Fonts issue for Roboto was just closed, noting that the new OpenType 1.8.2 spec has relaxed requirements which make at least Roboto valid: https://github.com/google/fonts/issues/738#issuecomment-317282256

Comment 28

[Thomas Wisniewski]

Given how many reports we're seeing from nightly users (bug 1387315 and on webcompat.com, etc), maybe we should go ahead and implement the OpenType changes for relaxed validation requirements sooner rather than later? (see the link in comment 26 for more context)

Comment 29

[Jonathan Kew [:jfkthame]]

The OTS update that landed in bug 1348788 has already addressed the OpenType 1.8.2 change.

However, some of the Google Fonts resources apparently have other flaws than the specific issue addressed there, which mean they are still out of spec, and will still be rejected by Nightly.

Comment 30

[Jonathan Kew [:jfkthame]]

For example, the error reported in bug 1331737 comment 3:

downloadable font: Layout: DFLT script doesn't satisfy the spec. DefaultLangSys is NULL (font-family: "Varela Round--Menu" style:normal weight:normal stretch:normal src index:0) source: https://fonts.gstatic.com/s/varelaround/v8/APH4jr0uSos5wiut5cpjrkWnNVpw0CtxFlw7ZW7Wg4I.woff2 (unknown)

is still an error according to OpenType 1.8.2, AFAICT; see https://www.microsoft.com/typography/otspec/chapter2.htm#scriptsLangs.

Comment 31

[Thomas Wisniewski]

Ah, I see. Thanks for the clarification!

Comment 32

[Albert Scheiner [:alberts]]

Just wanted to check out the change of bug 1348788, but now I can't even load the fonts at all anymore. Showing me a "Something went wrong" screen instead of fonts. See attachment with console errors

Comment 33

[Albert Scheiner [:alberts]]

Attachment: fonts.google.com-error-screen.png

Comment 34

[Kohei Yoshino [:kohei]]

(In reply to Albert Scheiner [:alberts] from comment #32)
> Just wanted to check out the change of bug 1348788, but now I can't even
> load the fonts at all anymore. Showing me a "Something went wrong" screen
> instead of fonts. See attachment with console errors

It's a separate bug 1387315.

Comment 35

[Alex Gibson [:agibson]]

Bug 1387315 has been closed as INVALID and this bug has been closed as WORKSFORME. 

I understand that this is something that only effects Firefox Nightly, but I want to make certain that we are saying it's OK for fonts.google.com not to work in Nightly any longer, and also for websites that use web fonts hosted on fonts.google.com not to render correctly?

Comment 36

[Mike Taylor [:miketaylr]]

I'm gonna re-open this and move it to Tech Evangelism to as a tracking bug around these issues.

Comment 37

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Per comment #36 - reopening

Comment 39

[Dave Crossland]

Behdad has fixed the underlying problem in the fonttools subsetter -
 https://github.com/fonttools/fonttools/commit/6eb807b55f4fcc55a9b5fd8f3e320c89428462dd - so when the fonttools copy used by the GF API is updated, Nightly should stop barfing :)

Comment 41

[Jonathan Kew [:jfkthame]]

(In reply to Dave Crossland from comment #39)
> Behdad has fixed the underlying problem in the fonttools subsetter -
>  https://github.com/fonttools/fonttools/commit/
> 6eb807b55f4fcc55a9b5fd8f3e320c89428462dd - so when the fonttools copy used
> by the GF API is updated, Nightly should stop barfing :)

Thanks, Dave (and Behdad for the underlying fix). Do you have any idea how soon an updated subsetter might be deployed on GF? Presumably there's testing and such like to be done before it goes live, which may take some time....

Comment 44

[Alexey Ten (Lynn)]

Solution from comment 10 doesn't work for me.
I have freshly installed Firefox from https://launchpad.net/~mozillateam/+archive/ubuntu/firefox-next
Version 	57.0b4
Build ID 	20170928234122

gfx.downloadable_fonts.otl_validation is false but still no fonts from google fonts

https://screenshots.firefox.com/8fFiKjUxdLpzL4Wq/toster.ru
https://screenshots.firefox.com/1vsR6fHPINi26BDx/fonts.google.com

Comment 45

[Alban Cousinié]

gfx.downloadable_fonts.otl_validation did the trick for me on 58.0a1.

Comment 46

[Andreas Bovens [:abovens]]

Google Docs now works for me in 57. (https://webcompat.com/issues/10505)
I still see issues on https://fonts.google.com/specimen/Roboto - some fonts are shown, most aren't.

Comment 47

[Karl Dubost💡 :karlcow]

font Poppins has issues with OTL validation.

Comment 48

[Karl Dubost💡 :karlcow]

Overlock font.

Comment 49

[Thomas Wisniewski]

Roboto has now been updated, and seems to be working fine for me on nightly builds: https://github.com/google/fonts/issues/738#issuecomment-337757289

Comment 50

[Thomas Wisniewski]

The other fonts in the related webcompat issues also seem to have been fixed, including the ones caused Google Docs to show the infamous "some fonts could not be loaded" message. Yay!

Comment 51

[Thomas Wisniewski]

And Dave Crossland has confirmed that the fix should be for all fonts, not just Roboto: https://github.com/mozilla/zilla-slab/issues/12#issuecomment-337777023

I'm not 100% sure if that means we can close this ticket or not?

Comment 52

[Karl Dubost💡 :karlcow]

yup. Let's close this as fixed (by proxy).

Comment 53

[Mike Taylor [:miketaylr]]

Great news, thanks everyone.