Status

defect
P3
normal
RESOLVED FIXED
3 years ago
5 months ago

People

(Reporter: admin, Unassigned)

Tracking

({dev-doc-complete, nightly-community, site-compat})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [gfx-noted][Workaround at comment 10], )

Attachments

(2 attachments)

Posted image 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
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
Component: Untriaged → Graphics: Text
Product: Firefox → Core
Summary: fonts → Can't load fonts on https://fonts.google.com/
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.
Flags: needinfo?(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.
Flags: needinfo?(jfkthame)
Priority: -- → P5
Whiteboard: [gfx-noted]
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/
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 10 → All
Hardware: x86_64 → All
Version: 52 Branch → Trunk
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?
Flags: needinfo?(jfkthame)
Duplicate of this bug: 1347277
(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.
Flags: needinfo?(jfkthame) → needinfo?(mats)
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!
Flags: needinfo?(mats)
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.
Did you check the browser console (not web console) for messages? Last I checked, the new web console UI wasn't showing them...
And if you set gfx.downloadable_fonts.otl_validation to false, does that "fix" things?
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.
cc'ing Dave at the Google Fonts team.
(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.)
(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.
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
Duplicate of this bug: 1357354
Does changing gfx.downloadable_fonts.otl_validation to false present any security risks?
(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.
(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!
Here is an issue over at google/fonts over on Github: https://github.com/google/fonts/issues/738
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.
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.
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 ?)
Duplicate of this bug: 1375609
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
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)
Flags: needinfo?(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.
Flags: needinfo?(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.
Ah, I see. Thanks for the clarification!
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
(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.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID
Resolution: INVALID → WORKSFORME
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?
Flags: webcompat?
I'm gonna re-open this and move it to Tech Evangelism to as a tracking bug around these issues.
Component: Graphics: Text → Desktop
Priority: P5 → P3
Product: Core → Tech Evangelism
Per comment #36 - reopening
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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 :)
Duplicate of this bug: 1389684
(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....
Whiteboard: [gfx-noted] → [gfx-noted][Workaround at comment 10]
Duplicate of this bug: 1403854
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
gfx.downloadable_fonts.otl_validation did the trick for me on 58.0a1.
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.
font Poppins has issues with OTL validation.
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
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!
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?
yup. Let's close this as fixed (by proxy).
Status: REOPENED → RESOLVED
Closed: 2 years ago2 years ago
Resolution: --- → FIXED
Great news, thanks everyone.
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.