Closed Bug 1244693 Opened 8 years ago Closed 8 years ago

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

Categories

(Core :: Graphics: Text, defect)

44 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla47
Tracking Status
firefox44 --- affected
firefox45 + fixed
firefox46 + fixed
firefox47 + fixed
relnote-firefox --- -

People

(Reporter: daniel.ritz.ch, Assigned: jfkthame)

References

Details

(Keywords: dev-doc-needed, site-compat)

Attachments

(1 file)

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.
Component: Untriaged → Graphics: Text
Product: Firefox → Core
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?
Component: Graphics: Text → Desktop
Product: Core → Tech Evangelism
Version: 44 Branch → Firefox 44
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.
(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.
[ 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.
(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.
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.
Attachment #8714757 - Flags: review?(jd.bugzilla)
Assignee: nobody → jfkthame
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
And moving the bug to Core::Gfx:Text, where we'll potentially take a workaround.
Component: Desktop → Graphics: Text
Product: Tech Evangelism → Core
Version: Firefox 44 → unspecified
(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 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.
Attachment #8714757 - Flags: review?(jd.bugzilla) → review+
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
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.
relnote-firefox: --- → ?
https://hg.mozilla.org/mozilla-central/rev/744a0bf0051a
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
> Target Milestone: --- → mozilla47
Not earlier?
OS: Unspecified → All
Hardware: Unspecified → All
Version: unspecified → 44 Branch
(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 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
Attachment #8714757 - Flags: approval-mozilla-beta?
Attachment #8714757 - Flags: approval-mozilla-aurora?
(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 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
Attachment #8714757 - Flags: approval-mozilla-beta?
Attachment #8714757 - Flags: approval-mozilla-beta+
Attachment #8714757 - Flags: approval-mozilla-aurora?
Attachment #8714757 - Flags: approval-mozilla-aurora+
Too late, 45 was already in beta in this time.
Maybe we want to relnote that for 46?
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?!!!
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
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.
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 ?
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.
(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
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.
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.
Summary: FF 44 fails to load some WOFF fonts → FF 44 fails to load some web fonts (WOFF or TrueType/OpenType)
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).
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: