1244693 - FF 44 fails to load some web fonts (WOFF or TrueType/OpenType)

Status: RESOLVED FIXED

(Core :: Graphics: Text, defect)

Description

[Daniel Ritz]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160123151951

Steps to reproduce:

Point browser at http://networks.nokia.com/portfolio/products


Actual results:

Headings like "Products" is a WOFF font, "Nokia Pure Headline Light". The font is not loaded, falls back to Helvetica. With FF 43 everything is OK. Works well with Safari and Chrome too. So this is a regression, even if the font itself has problems.

Console shows a ton of these:
downloadable font: Layout: DFLT table doesn't satisfy the spec. for script tag DFLT (font-family: "Nokia Pure Headline UltraLight" style:normal weight:normal stretch:normal src index:1) source: http://networks.nokia.com/sites/all/themes/nsn_2013/fonts/NokiaPureHeadline-UltraLight_latin+latin-ext_gdi.woff style2.css:1:5328
downloadable font: Layout: Failed to parse script table 0 (font-family: "Nokia Pure Headline UltraLight" style:normal weight:normal stretch:normal src index:1) source: http://networks.nokia.com/sites/all/themes/nsn_2013/fonts/NokiaPureHeadline-UltraLight_latin+latin-ext_gdi.woff style2.css:1:5328
downloadable font: GPOS: Failed to parse script list table (font-family: "Nokia Pure Headline UltraLight" style:normal weight:normal stretch:normal src index:1) source: http://networks.nokia.com/sites/all/themes/nsn_2013/fonts/NokiaPureHeadline-UltraLight_latin+latin-ext_gdi.woff style2.css:1:5328
downloadable font: rejected by sanitizer (font-family: "Nokia Pure Headline UltraLight" style:normal weight:normal stretch:normal src index:1) source: http://networks.nokia.com/sites/all/themes/nsn_2013/fonts/NokiaPureHeadline-UltraLight_latin+latin-ext_gdi.woff style2.css:1:5328
downloadable font: Layout: DFLT table doesn't satisfy the spec. for script tag DFLT (font-family: "Nokia Pure Headline Light" style:normal weight:300 stretch:normal src index:1) source: http://networks.nokia.com/sites/all/themes/nsn_2013/fonts/NokiaPureHeadline-Light_latin+latin-ext_gdi.woff


Expected results:

Load and display the font like other browsers and older FF versions.

Comment 1

[Jonathan Kew [:jfkthame]]

This is indeed a font error; it includes LangSysRecord entries under the 'DFLT' script, which violates the OpenType spec. (Those records belong under the 'latn' script tag.)

The new revision of OTS (OpenType Sanitizer) in FF44 has become stricter about errors in the OpenType layout tables, and now rejects the font. (See also discussion in bug 1239176.)

Moving this to Tech Evangelism. Do we have any contacts at Nokia who could get their font(s) fixed?

Comment 2

[Daniel Ritz]

Yes, the font is broken. I'll try to find the right contact at Nokia.

But please try to see this from a user perspective: The stricter OTS makes FF44 look bad in comparison. Older versions of FF and current versions of other browsers (Chrome, Safari and even IE11) display the font just fine. So the reaction of the typical user is "FF44 is broken". Even when technically the font is. So from a user perspective it's a clear regression.

Comment 3

[Jonathan Kew [:jfkthame]]

(In reply to Daniel Ritz from comment #2)
> Yes, the font is broken. I'll try to find the right contact at Nokia.
> 
> But please try to see this from a user perspective: The stricter OTS makes
> FF44 look bad in comparison. Older versions of FF and current versions of
> other browsers (Chrome, Safari and even IE11) display the font just fine. So
> the reaction of the typical user is "FF44 is broken". Even when technically
> the font is. So from a user perspective it's a clear regression.

Yes, understood.

The trouble is that if we ignore errors and try to make things "work" anyway (a long tradition in the Web world, sadly!), then authors/webmasters/whatever have no incentive to fix things; they probably won't ever realize their font is incorrect. In the long run, it's better for everyone if software and data all conforms to the same standards.

In this particular case, I suspect we might end up deciding that the error is essentially harmless and we'll just let it through and render the font anyway; but that's a slippery slope that easily leads to a "race to the bottom" where all thought of standards-compliance is lost amid the pressure to Just Make Everything Work. So I'm reluctant to rush in that direction unless it looks like this is a really widespread problem.

Comment 4

[Daniel Ritz]

[ Disclaimer: I don't speak for Nokia. ]

Thanks for answering so quickly to this report btw.

(In reply to Jonathan Kew (:jfkthame) from comment #3)
> (In reply to Daniel Ritz from comment #2)
> > Yes, the font is broken. I'll try to find the right contact at Nokia.
> > 
> > But please try to see this from a user perspective: The stricter OTS makes
> > FF44 look bad in comparison. Older versions of FF and current versions of
> > other browsers (Chrome, Safari and even IE11) display the font just fine. So
> > the reaction of the typical user is "FF44 is broken". Even when technically
> > the font is. So from a user perspective it's a clear regression.
> 
> Yes, understood.
> 
> The trouble is that if we ignore errors and try to make things "work" anyway
> (a long tradition in the Web world, sadly!), then
> authors/webmasters/whatever have no incentive to fix things; they probably
> won't ever realize their font is incorrect. In the long run, it's better for
> everyone if software and data all conforms to the same standards.
> 

That would be nice, but...

Authors and webmaster don't always control the fonts. They have to use what
they're given. Fonts don't just get fixed over night. Also I can't remember
having seen a _warning_ in console about the error in the font (correct me if
I'm wrong). Just breaking things w/o a warning is really bad. So this, IMHO,
should be a warning only for at least a year or so to give people time to fix
things. I know it wasn't done in bad faith. Stuff happens.
[ I'm a software engineer myself, so I know too well ] 

> In this particular case, I suspect we might end up deciding that the error
> is essentially harmless and we'll just let it through and render the font
> anyway; but that's a slippery slope that easily leads to a "race to the
> bottom" where all thought of standards-compliance is lost amid the pressure
> to Just Make Everything Work. So I'm reluctant to rush in that direction
> unless it looks like this is a really widespread problem.

Forgive me to say this, but... Sadly, FF's market has been dropping and keeps
dropping, losing to Chrome. At this point "works in Chrome, _used_ to work in FF"
should mean "fix it in FF asap". An end user only sees FF doesn't work, Chrome
does. They don't care about the technical reasons.

As for how widespread this particular problem is: the font is used everywhere at
Nokia, worldwide, internal and external, in customer facing products too. And
now with Alcatel-Lucent being integrated into Nokia, it's used even more.
Luckily only the "headline" font is affected, the "text" one works. So I
opted to fall back to the "text" version instead in what little I can control.

Also, I did contact some "brand" related email address.

Comment 5

[Jonathan Kew [:jfkthame]]

(In reply to Daniel Ritz from comment #4)

> Authors and webmaster don't always control the fonts. They have to use what
> they're given. Fonts don't just get fixed over night. Also I can't remember
> having seen a _warning_ in console about the error in the font (correct me if
> I'm wrong).

Actually, Firefox *did* give a warning in the console in earlier versions (I just double-checked that Nokia page in FF43, and the warnings are present). But I suspect that the proportion of web authors who routinely pay attention to warnings is minuscule. It's only when something "breaks" on their page that they take any notice.

> Just breaking things w/o a warning is really bad. So this, IMHO,
> should be a warning only for at least a year or so to give people time to fix
> things.

Agreed, in principle; but it's hard to know how to get warnings where they'll be heeded, short of putting them constantly in the faces of ordinary users....

(I sometimes think I'd like to have a top-of-page notification bar that slides in and says something like "Some fonts on this page were blocked because they do not conform to the OpenType specification". But I suspect ordinary users would find it really annoying -- more so than just rejecting the fonts and using a local fallback. I wonder what proportion of users notice/care whether the headings on Nokia's pages get their corporate font?)

A possible compromise position here would be to relax the validation of these tables in release builds, so that things "just work" for end users, but keep the stricter validation in Nightly / Developer Edition builds. Then there's at least a possibility that some web developers/authors will be alerted to the presence of errors in the fonts they're deploying, but end users will be unaffected.

Comment 6

[Jonathan Kew [:jfkthame]]

Attachment: On Beta/Release channels, allow OpenType Layout tables (GDEF/GPOS/GSUB) to pass through OTS unchecked, relying on harfbuzz to handle them safely

Migrating this patch from bug 1239176, and making it apply to release-mode builds only so as to try and keep a little pressure on authors to get their fonts fixed.

Comment 7

[Jonathan Kew [:jfkthame]]

And moving the bug to Core::Gfx:Text, where we'll potentially take a workaround.

Comment 8

[Daniel Ritz]

(In reply to Jonathan Kew (:jfkthame) from comment #5)
> (In reply to Daniel Ritz from comment #4)
> 
> > Authors and webmaster don't always control the fonts. They have to use what
> > they're given. Fonts don't just get fixed over night. Also I can't remember
> > having seen a _warning_ in console about the error in the font (correct me if
> > I'm wrong).
> 
> Actually, Firefox *did* give a warning in the console in earlier versions (I
> just double-checked that Nokia page in FF43, and the warnings are present).

Hmm...never seen it, so I tried again (with a small internal page I work on).
It warns and it doesn't :). It gives a warning the first time the font is loaded,
but then it's cached and the warning never shows again until it has to reload...

> But I suspect that the proportion of web authors who routinely pay attention
> to warnings is minuscule. It's only when something "breaks" on their page
> that they take any notice.
> 
> > Just breaking things w/o a warning is really bad. So this, IMHO,
> > should be a warning only for at least a year or so to give people time to fix
> > things.
> 
> Agreed, in principle; but it's hard to know how to get warnings where
> they'll be heeded, short of putting them constantly in the faces of ordinary
> users....
> 
> (I sometimes think I'd like to have a top-of-page notification bar that
> slides in and says something like "Some fonts on this page were blocked
> because they do not conform to the OpenType specification". But I suspect
> ordinary users would find it really annoying -- more so than just rejecting
> the fonts and using a local fallback. I wonder what proportion of users
> notice/care whether the headings on Nokia's pages get their corporate font?)
> 

Yes, a top-of-page notification is too annoying for normal users.
But when I do web development I'd find it useful. Maybe the top-of-page thing
could be done while the developer tools are open? This way it would reach the
right people while not affecting ordinary users.

For ordinary users maybe something like an icon with a warning sign in the
address bar, showing more information when clicked. Dunno, UI/UX is hard

> A possible compromise position here would be to relax the validation of
> these tables in release builds, so that things "just work" for end users,
> but keep the stricter validation in Nightly / Developer Edition builds. Then
> there's at least a possibility that some web developers/authors will be
> alerted to the presence of errors in the fonts they're deploying, but end
> users will be unaffected.

I think that's a good start. Thanks.

Comment 9

[John Daggett (:jtd)]

Comment on attachment 8714757 [details] [diff] [review]
On Beta/Release channels, allow OpenType Layout tables (GDEF/GPOS/GSUB) to pass through OTS unchecked, relying on harfbuzz to handle them safely

Review of attachment 8714757 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good. I think it would be a good idea to have this uplifted to aurora/beta. Definitely needs a release note too to highlight the fact that the Developer release may reject some fonts that the beta/release version accepts.

Comment 10

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/744a0bf0051a39d0757cf3ac8a40f05730f7ca34
Bug 1244693 - On Beta/Release channels, allow OpenType Layout tables (GDEF/GPOS/GSUB) to pass through OTS unchecked, relying on harfbuzz to handle them safely. r=jdaggett

Comment 11

[Jonathan Kew [:jfkthame]]

Release Note Request (optional, but appreciated)
[Why is this notable]: Some web fonts may be rejected (reporting an error in the web console) on Nightly and Developer Edition, even though they work on Beta/Release builds, due to stricter font validation.

[Suggested wording]: Developer Edition rejects web fonts with OpenType layout tables that violate the OpenType specification.

[Links (documentation, blog post, etc)]: See discussion in this bug.

Comment 13

[Kohei Yoshino]

Posted the site compatibility doc: https://fxsitecompat.com/en-CA/docs/2016/some-web-fonts-may-not-be-displayed-due-to-stricter-validation/

Comment 14

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/744a0bf0051a

Comment 15

[Daniel Ritz]

> Target Milestone: --- → mozilla47
Not earlier?

Comment 16

[Jonathan Kew [:jfkthame]]

(In reply to Daniel Ritz from comment #15)
> > Target Milestone: --- → mozilla47
> Not earlier?

That indicates the current development version where this change has just been applied. However, I'm going to request "uplift" to 46 (currently in the Aurora/Developer Edition channel) and 45 (Beta); if this is approved, it will end up shipping earlier -- I hope so.

Comment 17

[Jonathan Kew [:jfkthame]]

Comment on attachment 8714757 [details] [diff] [review]
On Beta/Release channels, allow OpenType Layout tables (GDEF/GPOS/GSUB) to pass through OTS unchecked, relying on harfbuzz to handle them safely

Approval Request Comment
[Feature/regressing bug #]: 1193050 (OTS update introduced stricter validation)

[User impact if declined]: Some webfonts (that previously worked) fail to load

[Describe test coverage new/current, TreeHerder]: Tested manually; note that the change affects behavior ONLY for beta/release builds, as we want to retain the stricter validation for nightly/dev edition to bring it to web dev's attention

[Risks and why]: Low risk -- allows fonts with out-of-spec OpenType Layout tables to be loaded via @font-face, but harfbuzz applies its own sanitization before using them, and we no longer call black-box system APIs like Uniscribe or DirectWrite to handle OT layout, which used to be the main risk.

[String/UUID change made/needed]: n/a

Comment 18

[Daniel Ritz]

(In reply to Jonathan Kew (:jfkthame) from comment #16)
> (In reply to Daniel Ritz from comment #15)
> > > Target Milestone: --- → mozilla47
> > Not earlier?
> 
> That indicates the current development version where this change has just
> been applied. However, I'm going to request "uplift" to 46 (currently in the
> Aurora/Developer Edition channel) and 45 (Beta); if this is approved, it
> will end up shipping earlier -- I hope so.

Ah ok. Thank you. Also for handling this so quickly :)

Comment 19

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8714757 [details] [diff] [review]
On Beta/Release channels, allow OpenType Layout tables (GDEF/GPOS/GSUB) to pass through OTS unchecked, relying on harfbuzz to handle them safely

Taking it as the bug is causing webcompat regression.

Should be in 45 beta 3

Comment 20

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/68fb23209078
https://hg.mozilla.org/releases/mozilla-beta/rev/060086e4af2e

Comment 21

[Kohei Yoshino]

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

MDN docs need a note, maybe.

Comment 26

[Sylvestre Ledru [:Sylvestre]]

Too late, 45 was already in beta in this time.
Maybe we want to relnote that for 46?

Comment 28

[khadem1386]

Hi
1-we have same Problem for "Persian fonts"  , and we can not embed these fonts. 
     A-"please only warning on console"
     B-could you please show some step to solve and making "valid font"

2-what about other Grate browser?!!!

Comment 29

[Jean-Yves Perrier [:teoli]]

I've added a note in:
https://developer.mozilla.org/en-US/Firefox/Releases/44#Miscellaneous
and
https://developer.mozilla.org/en-US/Firefox/Releases/46#Miscellaneous

I hope I have understood well ;-)

Comment 30

[sylvain baronnet]

Hi, I just spent 2 hours trying to figure out how to fix a font for Firefox and still have no clue...

I bought a "pro font" (Nexa) and converted it using Font Squirel.

Any help would be greatly appreciated

Comment 31

[Jonathan Kew [:jfkthame]]

Did you look in the console (Tools / Web Developer / Web Console) to see whether any font-related error messages are being reported? (You probably need to clear the browser cache and reload after opening the console, to ensure the font is freshly loaded and validated.) If Firefox is rejecting the font, it should log an error there specifying what aspect of it was bad.

Comment 32

[sylvain baronnet]

Thanks for your reply.

Yes I have error log : 

Layout: DFLT table doesn't satisfy the spec. for script tag DFLT (font-family: "nexa" style:normal weight:normal stretch:normal src index:1)
Layout: Failed to parse script table 0 (font-family: "nexa" style:normal weight:normal stretch:normal src index:1)
GPOS: Failed to parse script list table (font-family: "nexa" style:normal weight:normal stretch:normal src index:1)
rejected by sanitizer (font-family: "nexa" style:normal weight:normal stretch:normal src index:1)

But I have no idea how to fix that. Should I open it with a font editor and try to find these errors ?

Comment 33

[sylvain baronnet]

I found how to fix it with this link : https://chezsoi.org/lucas/blog/2016/02/11/en-fixing-fonts-that-raise-a-dflt-table-error-in-firefox/

The sed command in the article didn't work for me and I had to do it manually.

I'm not sure it is a good change for Firefox... Many old site won't bother (or notice) to fix their font in Firefox and it takes time to fix it. At least an article somewhere on Mozilla helping would be great.

Comment 34

[Jonathan Kew [:jfkthame]]

(I see you found a way to fix it, but I'll go ahead and post this, which I'd written before I saw your last comment.)

The problem is that the GPOS table's script list violates this OpenType requirement:

"If a Script table with the script tag 'DFLT' (default) is present in the ScriptList table, it must have a non-NULL DefaultLangSys and LangSysCount must be equal to 0."

(see under "Script List Table and Script Record" in [1]) by including LangSysRecord entries.

If you know how to fix OpenType tables, and your license for the font allows it, you could fix that by removing the LangSysRecords and ensuring the 'DFLT' script has only a DefaultLangSys. Alternatively, report the problem to the font developer/vendor and ask them to fix it, because their font does not follow the OpenType specification correctly.

(Note that this strict validation is being removed in newer release versions of Firefox -- see discussion earlier in this bug -- but if you need the font to work for users with FF44, that's no immediate help.)


[1] https://www.microsoft.com/typography/otspec/chapter2.htm

Comment 35

[sylvain baronnet]

Thanks for your help.

I had to remove empty <ScriptTag value="DFLT"/> and whole <LangSysRecord> entries

Good to know it's 44 only. I'm testing in nightly and still have the strict validation though so i'm not sure.

Comment 36

[Jonathan Kew [:jfkthame]]

If you review all the discussion above, you'll see that the current situation is that we have the stricter validation on Nightly and Developer Edition (so that developers/authors are made aware when they have "bad" fonts), but for the Beta and Release channels (i.e. the great mass of users), that validation is bypassed so that such fonts will work for them.

It's not ideal, and we'll probably be making further changes in this area, but as of now your end users (if they're updated to Firefox 45) shouldn't be having this problem any longer.

Comment 40

[Thomas Wisniewski]

I agree that it's good to have *something* validating web fonts, but without any obvious warnings logged by default, it just looks like Firefox is to blame, rather than the font itself. I would suggest that we ensure that the console warnings are always logged, to avoid regressions. If not also doing something more drastic on the rendered page than merely falling back to another font (if we feel that will drive more people to fix their fonts).