1417242 - Some characters don't display anymore with new Firefox 57 while visiting lemonde.fr

Status: RESOLVED DUPLICATE of bug 1393259

(Core :: Security: Process Sandboxing, defect)

Description

[Emmanuel Lazard]

Attachment: Capture d’écran 2017-11-14 à 23.29.50.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171112125346

Steps to reproduce:

Just visit lemonde.fr with new Firefox 57


Actual results:

Some text doesn't display anymore


Expected results:

Correct page display!

Comment 3

[Jonathan Kew [:jfkthame]]

I think it's premature to close this as a duplicate of bug 1404919 without more details. It may be that a different font manager or other utility is involved, and we need to add further sandbox rules to account for it.

Emmanuel, can you confirm whether you are using a font management utility, or anything else non-standard about your font setup?

If you go to about:config, find the setting security.sandbox.content.level, and change it to 1 (and then restart Firefox), does that help?

Comment 4

[Emmanuel Lazard]

I do not use any font management utility on my Mac.

And yes, if I change security.sandbox.content.level to 1, characters display correctly! Change back to 3 and it's broken again.

Very few of my visited websites are affected.
One is lemonde.fr, the other is http://forum.othello.no/

Comment 5

[Emmanuel Lazard]

By the way, I've tried with all my extensions disabled, just in case. No change.

Comment 6

[Jonathan Kew [:jfkthame]]

That's interesting; this looks a lot like some issues we've seen with font manager utilities, but apparently that's not the cause of the problem here.

Could you please attach a screenshot of the breakage you see on http://forum.othello.no/ as well? (I'm curious if it affects all the text there, or which specific parts.)

If you open Font Book, find Helvetica in the list of "All fonts", and click the arrow to expand the list of individual styles; and then select the Regular face, what does the right-hand font information panel show for "Location"? (If it shows a sample of the font, instead of the font info panel, choose Show Font Info from the View menu to switch it.)

Comment 7

[Jonathan Kew [:jfkthame]]

Actually, after looking more closely, the font I'm most interested in from your Font Book list isn't Helvetica, but Georgia. What does Font Book report in its font information about Georgia Regular?

Comment 8

[Emmanuel Lazard]

Attachment: forum.othello.no at 80% showing boxes

Comment 9

[Emmanuel Lazard]

Location: /Library/Fonts/Georgia.ttf
Location: /System/Library/Fonts/Helvetica.dfont

Comment 10

[Jonathan Kew [:jfkthame]]

Very puzzling: those look like exactly the normal, expected font file locations, and shouldn't cause any problems.

Font Book has a feature to "Look for Enabled Duplicates" (in the Edit menu). Does this report any duplicate fonts (particularly, anything about Georgia, which seems to be the problem)?

If you disable the Georgia font (select it in Font Book, and choose Disable from the Edit menu), does that make the problem go away, or are other fonts also affected? If you re-enable Georgia, does the problem immediately come back?

Comment 11

[Emmanuel Lazard]

There were no enabled duplicates.
Some fonts, like Georgia, were duplicates but I had already solved the issue by disabling them.
To be sure I deleted one copy of Georgia so I had only one left.
-> No change

I tried to disable Georgia but coundn't! More precisely, font book would tell me the font was disabled (but Firefox would see no change) and when I launch Font book again, Georgia would be enabled...

BUT I then tried to clean font caches with Onyx (utility program) and problem is gone! Pages now display correctly even after quitting Firefox and restarting the mac.

Obviously, I can't do any more tests on my office mac but later tonight I'll be home where I have another mac with the issue, so I'll try to figure out which font caches affect display in Firefox.

Comment 12

[Jonathan Kew [:jfkthame]]

Interesting! I'm glad the problem seems to be gone (at least on that machine), but obviously we'd still like to understand better what was happening here, and if there's something we can do to avoid such issues.

Can you by any chance remember the filename and location of the Georgia copy that you deleted? Did you just move a file to the Trash, or did you also completely empty the Trash?

Any further details you can provide after testing at home would be really appreciated. Thanks for your efforts to help investigate this!

Comment 13

[Emmanuel Lazard]

The other copy was in my home library folder : lazard/library/font
I moved it to the trash (directly from font book) and didn't empty it.

Comment 14

[Kohei Yoshino]

So is this probably a dup of Bug 1417420?

Comment 15

[Jonathan Kew [:jfkthame]]

(In reply to Kohei Yoshino [:kohei] from comment #14)
> So is this probably a dup of Bug 1417420?

It's unclear at this point. Bug 1417420 refers to use of font-manager utilities (specificially FontAgent), but in this case the user says "I do not use any font management utility" (comment 4), so the failure seems to have a different cause.

Comment 16

[Emmanuel Lazard]

I tried at home: cleaning all font caches except system cache didn't do any good.
I guess cleaning system cache would resolve the issue as on my office mac but then I wouldn't be able to do further tests :)
And no, I do not use any obvious font management utility.

Comment 17

[Haik Aftandilian [:haik]]

Emmanuel, could you run the command below and collect the output? It might help us figure out what's going on. It will record the paths to all fonts in your system (and more details about each font). If you're comfortable with sharing that information, you could attach it to this bug or privately email it to me or Jonathan.

To run the command, open the Terminal app (from /Applications/Utilities) and type the following and hit return. It will create/overwrite the file fontData.txt in your home directory and fill it with the font information.

  system_profiler SPFontsDataType > ~/fontData.txt

Alternatively, take a look at the output yourself and see if you see any unexpected fonts there. This command will just print the font paths without extra information.

  system_profiler SPFontsDataType|grep "Location:"

Comment 18

[Emmanuel Lazard]

Attachment: fontData.txt

Comment 19

[Emmanuel Lazard]

I think I have the culprit.
Checking fonts locations, I found that I had an old program, Cassio, that had a directory with fonts:
      Location: /Users/lazard/Documents/Cassio/Fichiers auxiliaires/Fonts/Georgia

I've never asked font book to load them but it seemed that was what was confusing Firefox.
I deleted the directory, restarted the mac and problem solved!

Comment 20

[Jonathan Kew [:jfkthame]]

Yes, I was just looking at the fontData.txt file, saw that file listed, and was about to post a comment here. The problem occurs because that's the copy of Georgia that the system is choosing as the "active" one, but the sandbox rules prevent the Firefox content process from accessing it. So when a site calls for Georgia, we end up with an unusable font object.

I notice you also have an obsolete copy of Georgia (in the old "font suitcase" format, I think) in /Users/lazard/Library/Fonts, which will probably be used in preference to the newer .ttf-format files in /Library/Fonts. This doesn't cause the same issue, because the ~/Library/Fonts directory is a standard location that is available to the content process, but I'd still advise removing the older version of the font.

Haik, this suggests to me that we should probably try to detect non-standard font locations on chrome-process startup and add them to the sandbox rules, so users don't run into this kind of failure except in the (rare) case that such a location gets added on the fly.

Comment 21

[Haik Aftandilian [:haik]]

(In reply to Emmanuel Lazard from comment #19)
> I think I have the culprit.

Thanks, Emmanuel! That makes sense and I'm glad you got it working. There are a few other fonts in the list that could cause a similar issue. See below for explanation.

  /Users/lazard/Documents/Cassio/Fichiers auxiliaires/Fonts/Arial Rounded Bold
  /Users/lazard/Documents/Cassio/Fichiers auxiliaires/Fonts/Georgia
  /Users/lazard/Documents/Cassio/Fichiers auxiliaires/Fonts/New York
  /Users/lazard/Documents/Cassio/Fichiers auxiliaires/Fonts/Palatino
  /Users/lazard/Documents/Cassio/Fichiers auxiliaires/Fonts/Times New Roman

The Mac sandbox in Firefox 56+ allows fonts from non-standard directories if the font has a font filename extension such as .otf or .dfont. From your list, the above fonts will fail to load in Firefox web content processes and could cause rendering issues like what you encountered. i.e., they're not in a standard font location and don't have filename extensions.

We are planning to improve this with bug 1393259 so that fonts work regardless of where they are or their filename, but it's still under development. We will look at what we could do in the meantime, but if this is rare scenario waiting for the proper fix in bug 1393259 might be the best option.

Comment 22

[Haik Aftandilian [:haik]]

(In reply to Jonathan Kew (:jfkthame) from comment #20)
> Haik, this suggests to me that we should probably try to detect non-standard
> font locations on chrome-process startup and add them to the sandbox rules,
> so users don't run into this kind of failure except in the (rare) case that
> such a location gets added on the fly.

OK, I agree. I'm hoping to address this by remoting font access with bug 1393259 and have a prototype semi-working. The remoting would only be used when the font fails to load. I'm considering whitelisting the fonts at startup the fallback solution in case remoting doesn't "pan out". I should have a design we can discuss within a week or so on bug 1393259.

Comment 23

[Emmanuel Lazard]

Thanks for your help and for all the work you're doing on Firefox.
I hope my issue helped you to improve Firefox.
Regards

Comment 24

[Haik Aftandilian [:haik]]

Thanks for reporting the issue and helping us debug/workaround the problem. Closing this bug as a duplicate of 1393259 where we plan to address this.