User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:56.0) Gecko/20100101 Firefox/56.0 Build ID: 20170926190823 Steps to reproduce: Since the latest update (56), fonts are not displaying. Each character displays as a letter A in a box. I’ve done a profile refresh, which has brought some text back to being readable but not all and some pages – this bug reporter included – are still not displaying. I’ve had to type this offline and paste into the text box.

This sounds suspiciously similar to other bugs we've seen involving fonts and the content sandbox, though I thought they were supposed to be fixed before the Firefox 56 release. To test this possibility, if you go to about:config and change the security.sandbox.content.level preference to 1 (if you can see enough text to do so!), and then restart Firefox, does that make any difference? (If no text is readable in about:config, you could probably make the change "blind": paste the preference name security.sandbox.content.level into the search field at the top, to filter the list of prefs down to just that entry; then double-click it to bring up the edit panel where you can enter the new value "1" and click OK or press Return; then quit and restart the browser.)

Fantastic! I did that and it worked. I opened up lots of different pages on different sites to check and it's sorted. Thank you so much!

OK, that's great -- but now we need to figure out why the sandbox broke fonts for you, even though we supposedly fixed this issue already (that was bug 1382260). Dan, do you use some kind of font management software, other than simply installing fonts in the standard system/user font library folders? Any and all details you can give about your font configuration may be helpful. Haik, it looks like we need to look again at fonts-vs-sandbox issues. :(

I'm a graphic designer, on a Mac (OS X Yosemite (10.10.5)), so I do use Extensis Suitcase Fusion 4 (Version 15.0.6 (523)) for additional fonts for projects. This issue is affecting my colleagues machines as well as my Mac at home which is a bit older and where Suitcase was installed but is not active because of OS version incompatibility. I use Apple's font book for my additional fonts.

Do you by any chance have some fonts that are still packaged in the old Mac "suitcase" format? Or indeed in any file format *other* than .otf, .ttf, .ttc, .otc, and .dfont?

Not as far as I know. I mean, they may exist in a folder on the hard drive somewhere as some of these fonts are going on 20 years old, but they're not in use. Most are OpenType, TrueType or Type 1 Postscript formats.

Dan, thank you for filing a bug on this. (In reply to Dan from comment #6) > Not as far as I know. I mean, they may exist in a folder on the hard drive > somewhere as some of these fonts are going on 20 years old, but they're not > in use. Most are OpenType, TrueType or Type 1 Postscript formats. Running the following command from the Terminal (/Applications/Utilities/Terminal) should print a list of all the font file extensions you're using (and how many of each). For example, $ system_profiler SPFontsDataType|grep Location|awk -F . '{print $NF}'|sort|uniq -c 6 dfont 74 otf 107 ttc 86 ttf (I haven't tried this command on OS X 10.10 yet.) At the moment, our sandbox will allow files ending in .otf, .ttf, .ttc, .otc, and .dfont. It could be that you have fonts with a different extension and we'll have to fix the browser sandbox rules to account for that. I'm not an expert on fonts, but the Wikipedia page on it lists type 1 postscript fonts as having extension .pfm, .afm, .inf [1]. If the above command doesn't work for you, there are some other debugging steps we can try. Thanks! 1. https://en.wikipedia.org/wiki/PostScript_fonts#Type_1

[Tracking Requested - why for this release]: A regression in Firefox 56, affecting a limited number of users (I think not many.)

I'll track it for now for 56, while we're still gathering info. We should at least aim to fix this in 57.

(In reply to Kohei Yoshino [:kohei] from comment #8) > [Tracking Requested - why for this release]: A regression in Firefox 56, > affecting a limited number of users (I think not many.) I've just seen 2 support requests (Italian local forum) reporting that all Google websites were broken. Both were solved by setting the pref to 1. That's 2 in 48 hours, based on the traffic and the number of people that actually take the time to subscribe and report errors, I don't think the number of affected users is so small.

esr52 shouldn't be affected, as the level-3 content process sandboxing landed for firefox 56 (bug 1332190, bug 1377522) and hasn't been uplifted to esr.

Running the Terminal Command for fonts I get the following fonts showing up. 1 0/4224907304/Zapfino 1 0/4280999599/CourierFinalDraft-Regular 1 0/982889619/NewYork 1 00/4192602106/ArialRoundedMTBold 1 05/1180394972/Arial-BoldItalicMT 1 05/1492793661/Arial-BoldMT 1 05/1614180915/TimesNewRomanPS-ItalicMT 1 05/1693275109/TimesNewRomanPS-BoldMT 1 05/2516098749/ArialMT 1 05/2975550750/Arial-ItalicMT 1 05/3476578673/TimesNewRomanPSMT 1 05/881481668/TimesNewRomanPS-BoldItalicMT 1 1/1059143354/ArmorPiercing 1 1/1831566355/Caeldera 1 1/521604557/Handwriting-Dakota 1 3/3362759721/ThinLine 1 35/1235237077/ArialNarrow-Italic 1 35/2968590679/Arial-Black 1 35/3099987542/CenturyGothic-Bold 1 35/560703140/ArialNarrow-Bold 1 35/691253589/ArialNarrow-BoldItalic 1 35/94516811/ArialNarrow 1 4/2147859847/Thirteen 1 5/1206434005/Courier-Bold 1 5/1895736744/BadaBoomBB 1 5/3544212452/Courier 1 5/4261440230/WhoopAss 1 5/654371983/FatStackBB 1 5/998110304/DamnNoisyKids 1 51/3235701920/CopperplateGothic-Bold 1 51/4268107926/CopperplateGothic-Light 1 51/791975400/EurostileBold 1 60/1187980934/CourierNewPS-BoldMT 1 60/221774959/CourierNewPS-BoldItalicMT 1 60/2236454870/CourierNewPSMT 1 60/824920274/CourierNewPS-ItalicMT 1 8/1315692521/Palatino-Italic 1 8/1964466933/Palatino-Bold 1 8/3513665906/Palatino-BoldItalic 1 8/81389000/Palatino-Roman 2 bmap 11 dfont 1 fontvault/SA/l/TT/freefont/Gunship/1/2127239866/Gunship 254 otf 39 scr 108 ttc 113 ttf

(In reply to Jonah Lee Walker from comment #13) > Running the Terminal Command for fonts I get the following fonts showing up. ... > 2 bmap > 11 dfont > 1 fontvault/SA/l/TT/freefont/Gunship/1/2127239866/Gunship > 254 otf > 39 scr > 108 ttc > 113 ttf Thanks, Jonah. This tells me you have some .scr and .bmap fonts registered in the system, but also several paths in your list don't have an extension and I don't know if those are actual font file. I'm going to build a version of Firefox that allows .scr and .bmap.

I'm not sure if this is the right bug, but we received a ton of duplicate issues around Malalyalam fonts not displaying -- all these users were from Firefox Quantum sprints in India: https://github.com/webcompat/web-bugs/issues/11422

Oh, most of these users reported from Linux and Windows... not macOS. Sorry.

Here's a build of Firefox 56 that allows additional font types. https://queue.taskcluster.net/v1/task/OB85-8uxQNe2o0wcpaENwg/runs/0/artifacts/public/build/target.dmg Jonah, would you be able to test with the above build and see if you still experience any font issues? You'll have to revert security.sandbox.content.level to 3 in about:config in order to test.

(In reply to Haik Aftandilian [:haik] from comment #14) > (In reply to Jonah Lee Walker from comment #13) > > Running the Terminal Command for fonts I get the following fonts showing up. > ... > > 2 bmap > > 11 dfont > > 1 fontvault/SA/l/TT/freefont/Gunship/1/2127239866/Gunship > > 254 otf > > 39 scr > > 108 ttc > > 113 ttf > > Thanks, Jonah. This tells me you have some .scr and .bmap fonts registered > in the system, but also several paths in your list don't have an extension > and I don't know if those are actual font file. I'm going to build a version > of Firefox that allows .scr and .bmap. The .scr and .bmap files will (I think) be bitmaps ("screen fonts") that accompany individual PostScript Type1 fonts which are typically in extension-less files. This was common on classic Mac OS, and so users who had extensive font collections in pre-OS X days and have brought these fonts forward to newer systems may still be using them. So (for example) I'm guessing that "Handwriting-Dakota" is a Type1 font resource, and there's a matching bitmap resource in a .scr or .bmap file; and for it to work, we'd need access to *both* of these. Without read access to the Type1 files, I don't think the .scr and .bmap files by themselves will be much use. (It's also possible that some of these are legacy resource-fork TrueType fonts, which could exist in either "font suitcase" format (Macintosh file type 'FFIL') or as individual font resource files (type 'tfil', IIRC). In either case, it was common for such files to have no extension, back in the days when the OS dependent purely on type/creator codes.)

It sounds like these may be legacy fonts, while I do see a couple of duplicate reports, maybe this is something we can aim to fix in 58 but I think it is unlikely for the 56 timeframe. Is there anything we can do to detect the problem and avoid trying to load those fonts, or fall back differently... any workaround for 58/57?

I'm working on a low-risk fix for 58 that we could uplift to 57 and 56 if it meets the uplift approval criteria. See link to a build with the fix below. In this bug, duplicate bug 1405459, and duplicate bug 1407294, the submitters were all using Extensis Suitcase Fusion font manager. Suitcase Fusion (by default) stores fonts in ~/Library/Extensis/Suitcase Fusion/Suitcase Fusion.fontvault and appears to sometimes rename fonts removing their filename extensions. Our existing whitelist rules for fonts don't cover that directory (which is specific to a 3rd party product) or fonts that don't have extensions outside of the normal font locations and that prevents the fonts from being loaded and causes the display issues. I have a build of Firefox 56/Release available below. If anyone experiencing the problem could test with this build of Firefox, that would help us confirm it will address the problem. Make sure to revert security.sandbox.content.level to 3 in about:config and restart before testing. https://queue.taskcluster.net/v1/task/W_J5iJbSTVi0cxwYRF_F9Q/runs/0/artifacts/public/build/target.dmg Work to solve this in a more general way is going to be done in bug 1393259.

(In reply to Haik Aftandilian [:haik] from comment #21) > I'm working on a low-risk fix for 58 that we could uplift to 57 and 56 if it > meets the uplift approval criteria. See link to a build with the fix below. > > In this bug, duplicate bug 1405459, and duplicate bug 1407294, the > submitters were all using Extensis Suitcase Fusion font manager. Suitcase > Fusion (by default) stores fonts in ~/Library/Extensis/Suitcase > Fusion/Suitcase Fusion.fontvault and appears to sometimes rename fonts > removing their filename extensions. Our existing whitelist rules for fonts > don't cover that directory (which is specific to a 3rd party product) or > fonts that don't have extensions outside of the normal font locations and > that prevents the fonts from being loaded and causes the display issues. > > I have a build of Firefox 56/Release available below. If anyone experiencing > the problem could test with this build of Firefox, that would help us > confirm it will address the problem. Make sure to revert > security.sandbox.content.level to 3 in about:config and restart before > testing. > > > https://queue.taskcluster.net/v1/task/W_J5iJbSTVi0cxwYRF_F9Q/runs/0/ > artifacts/public/build/target.dmg > > Work to solve this in a more general way is going to be done in bug 1393259. Yes this nightly build solved the issue when set back to level 3.

(In reply to Haik Aftandilian [:haik] from comment #21) > I'm working on a low-risk fix for 58 that we could uplift to 57 and 56 if it > meets the uplift approval criteria. See link to a build with the fix below. > > In this bug, duplicate bug 1405459, and duplicate bug 1407294, the > submitters were all using Extensis Suitcase Fusion font manager. Suitcase > Fusion (by default) stores fonts in ~/Library/Extensis/Suitcase > Fusion/Suitcase Fusion.fontvault and appears to sometimes rename fonts > removing their filename extensions. Our existing whitelist rules for fonts > don't cover that directory (which is specific to a 3rd party product) or > fonts that don't have extensions outside of the normal font locations and > that prevents the fonts from being loaded and causes the display issues. > > I have a build of Firefox 56/Release available below. If anyone experiencing > the problem could test with this build of Firefox, that would help us > confirm it will address the problem. Make sure to revert > security.sandbox.content.level to 3 in about:config and restart before > testing. > > > https://queue.taskcluster.net/v1/task/W_J5iJbSTVi0cxwYRF_F9Q/runs/0/ > artifacts/public/build/target.dmg > > Work to solve this in a more general way is going to be done in bug 1393259. Sorry I meant this post, yes this solved the issue when set to level 3.

Thanks for testing the fix, Jonah. The patch posted for review whitelists files within a directory named *.fontvault. With the Extensis font manager, the default location of the fonts is ~/Library/Extensis/Suitcase Fusion/Suitcase Fusion.fontvault. If the user selects the option to store the fonts at another location, the user can choose the location and the .fontvault extension is automatically added to the name the user provides. I tested RightFont and FontExplorer and found they didn't rename font files (in the testing I did) so our existing whitelist rules worked.

Comment on attachment 8919525 [details] Bug 1404919 - Whitelist Extensis Suitcase Fusion fontvaults. https://reviewboard.mozilla.org/r/190360/#review195858 ::: security/sandbox/mac/SandboxPolicies.h:350 (Diff revision 1) > + ; bug 1404919 > + ; Read access (recursively) within directories ending in .fontvault > + (allow file-read* (regex #"\.fontvault/")) Ouch. I was really hoping this would end up being just a single directory in $HOME to whitelist. Do we have any sense of if it's common to use an alternate location for this, or if almost everyone is using `~/Library/Extensions/Suitcase Fusion/Suitcase Fusion.fontvault`?

(In reply to Alex Gaynor [:Alex_Gaynor] from comment #26) > Ouch. I was really hoping this would end up being just a single directory in > $HOME to whitelist. > > Do we have any sense of if it's common to use an alternate location for > this, or if almost everyone is using `~/Library/Extensions/Suitcase > Fusion/Suitcase Fusion.fontvault`? I don't think we have any way to really know this, but IMO it's likely the majority of users leave the "fontvault" in its default location. Still, I think we need to deal with this for arbitrary locations -- otherwise the breakage those users experience can be really severe, and the reason for it is far from obvious to them. The user in this scenario hasn't done anything that appears "wrong" or "unsupported"; they're using their utility software as designed, and it should Just Work™ for them.

Comment on attachment 8919525 [details] Bug 1404919 - Whitelist Extensis Suitcase Fusion fontvaults. https://reviewboard.mozilla.org/r/190360/#review195858 > Ouch. I was really hoping this would end up being just a single directory in $HOME to whitelist. > > Do we have any sense of if it's common to use an alternate location for this, or if almost everyone is using `~/Library/Extensions/Suitcase Fusion/Suitcase Fusion.fontvault`? To add to what Jonathan commented on the bug, I don't have a good sense of how many users use an alternate location. Of the 3 submitters who filed a bug on this, one provided full "system_profiler SPFontsDataType" output and that revealed they were using the default location. Unfortunately this is a somewhat nasty regression for those users affected because the browser can become totally unusable. I'd be open to limiting this to the default location, but I think Jonathan has valid points, and the probability that this would expose a user's sensitive data in the event of a remote-code-execution bug is very low. (The user would have to be storing sensitive data in a directory ending in .fontvault.) I think this is another reason we need a more general fix (bug 1393259) so that we don't have to add font exceptions or be dependent on 3rd party paths.

Comment on attachment 8919525 [details] Bug 1404919 - Whitelist Extensis Suitcase Fusion fontvaults. https://reviewboard.mozilla.org/r/190360/#review195946 ::: security/sandbox/mac/SandboxPolicies.h:208 (Diff revision 1) > (allow-shared-preferences-read "com.apple.ATS") > (allow file-read-data (literal "/Library/Preferences/.GlobalPreferences.plist")) > > (allow file-read* > (subpath "/Library/Fonts") > + (subpath "/System/Library/Fonts") I believe we already have all of `/System` whitelisted (line 75).

Comment on attachment 8919525 [details] Bug 1404919 - Whitelist Extensis Suitcase Fusion fontvaults. https://reviewboard.mozilla.org/r/190360/#review195946 > I believe we already have all of `/System` whitelisted (line 75). We do. Thanks. Fixed.

Pushed by haftandilian@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ce9788d3ce4f Whitelist Extensis Suitcase Fusion fontvaults and /System/Library/Fonts. r=Alex_Gaynor

Guys don't be mad, we're just classic users and for myself I don't know no **** in programms. Some stuff you're discussing are abstract to me so to be clear and, hopefully helpefull, Suitcase is organised by default location so if that's the problem we can fix it. Just make it simple if you may. Cheers

Seems like a pretty rare situation, but pretty terrible for those affected. Too late for 56 at this point, but it seems worth a Beta nomination for 57 at least?

Comment on attachment 8919525 [details] Bug 1404919 - Whitelist Extensis Suitcase Fusion fontvaults. Approval Request Comment [Feature/Bug causing the regression]: Read access restrictions in the Mac content process sandbox in build 56. [User impact if declined]: Mac users using the third party Extensis Suitcase Fusion font manager may have display issues with their fonts making web pages unreadable. Specifically, characters will be displayed as boxes instead of text. [Is this code covered by automated tests?]: No [Has the fix been verified in Nightly?]: No. This is difficult to reproduce without specific fonts. The fix was tested by the submitter on a build 56 try build. I instrumented the code in order validate the fix without the problematic fonts. [Needs manual test from QE? If yes, steps to reproduce]: No [List of other uplifts needed for the feature/fix]: None [Is the change risky?]: No [Why is the change risky/not risky?]: It adds a whitelist rule to the Mac content sandbox policy making the sandbox less restrictive so nothing new would be blocked. [String changes made/needed]: None

Comment on attachment 8919525 [details] Bug 1404919 - Whitelist Extensis Suitcase Fusion fontvaults. Pretty bad ux, taking it in 57 as the risk seems minimal and should not have a side effect

(In reply to Jonathan Kew (:jfkthame) from comment #1) > This sounds suspiciously similar to other bugs we've seen involving fonts > and the content sandbox, though I thought they were supposed to be fixed > before the Firefox 56 release. To test this possibility, if you go to > about:config and change the security.sandbox.content.level preference to 1 > (if you can see enough text to do so!), and then restart Firefox, does that > make any difference? > > (If no text is readable in about:config, you could probably make the change > "blind": paste the preference name security.sandbox.content.level into the > search field at the top, to filter the list of prefs down to just that > entry; then double-click it to bring up the edit panel where you can enter > the new value "1" and click OK or press Return; then quit and restart the > browser.) This worked for me too. Thank you . Awesome I had found this solution elsewhere since posting my issue. It's frustrating when updates are released and not fully checked. I waste so much of my time trying to fix these things.

Ian, thanks for the report. Could you confirm if you are using a font manager such as Extensis Suitcase Fusion?

(In reply to Haik Aftandilian [:haik] from comment #42) > Ian, thanks for the report. Could you confirm if you are using a font > manager such as Extensis Suitcase Fusion? Hi. Yes, I'm using Suitcase fusion

It's all good with the 57th version. All set up, and it's a beautiful version too. Thanks you all guys it's nice to have to have a readable browser now

we got occasional support requests about this problem continuing in 57 with Fontexplorer X Pro (this time with boxes of [?]): https://support.mozilla.org/en-US/questions/1185331 https://www.camp-firefox.de/forum/viewtopic.php?f=1&t=122762

(In reply to [:philipp] from comment #46) > we got occasional support requests about this problem continuing in 57 with > Fontexplorer X Pro (this time with boxes of [?]): > https://support.mozilla.org/en-US/questions/1185331 > https://www.camp-firefox.de/forum/viewtopic.php?f=1&t=122762 Yes, this is a known issue: this will happen for FontExplorer users if they have fonts in the legacy Mac "suitcase" format activated from arbitrary locations (outside the standard Library/Fonts folders). The fix in bug 1382260 addressed the problem for FontExplorer (and other font managers) provided the files have a "known" font-filetype extension (.ttf, .otf, etc) but legacy suitcase files often have no filename extension at all, and so are not recognized by that patch. Haik is aiming to implement a more general solution in bug 1393259.