we have seen a number of user reports about fonts not correctly displaying on some sites (boxed A's), that are very similar to bug 1404919. here's one example: https://support.mozilla.org/en-US/questions/1185180 this time around the problem is happening with the third-party tool Font Agent Pro and regressing in 57 though. changing security.sandbox.content.level to 2 also solves the problem for those users.

We need to know where Font Agent Pro stores the fonts it is managing; is there a standard/fixed location for this that we can whitelist for the sandbox?

From briefly installing the trial version of FontAgent, it looks like it puts locally-activated fonts into a location under ~/Library/Application Support/, similar to what Adobe's fontsync does. So we should probably add this to the sandbox rules.

something similar got reported about "Font Explorer X Pro" at https://support.mozilla.org/questions/1185331.

[Tracking Requested - why for this release]: It's a regression from Firefox 57, breaking text rendering on macOS.

Pushed by jkew@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/10476f6075ae Add the path used by FontAgent to the sandbox rules on macOS. r=haik

[:philipp] The fix here should appear in today's Nightly build (2017-11-16) in a few hours; if we could get confirmation that it fixes the problem for affected users, that would be great.

(In reply to [:philipp] from comment #3) > something similar got reported about "Font Explorer X Pro" at > https://support.mozilla.org/questions/1185331. See also bug 1382260. A fix was landed there which should avoid the issue for Font Explorer users with .ttf/.otf font files, but I suspect that if Font Explorer (a or similar utility) is used to activate old "suitcase"-format fonts from non-standard locations, the problem will still exist. Bug 1393259 aims to solve this issue in a more general way.

Please request Beta approval on this when you get a chance. We should probably keep this on the radar for a dot release ride-along for 57 too.

(In reply to Ryan VanderMeulen [:RyanVM] from comment #10) > Please request Beta approval on this when you get a chance. We should > probably keep this on the radar for a dot release ride-along for 57 too. Yes, agreed. I was waiting to see if we could get feedback from any affected users [comment 7] now that the fix is available in Nightly, but given the nature of the patch (just adding a path to the sandbox rules) I don't see any significant risk in uplifting it.

Comment on attachment 8928511 [details] [diff] [review] Add the path used by FontAgent to the sandbox rules on macOS Approval Request Comment [Feature/Bug causing the regression]: content-process sandboxing [User impact if declined]: potential for broken font rendering for users of the FontAgent utility, depending on individual font configuration [Is this code covered by automated tests?]: no [Has the fix been verified in Nightly?]: currently awaiting feedback from affected users, but the fix is trivial [Needs manual test from QE? If yes, steps to reproduce]: install FontAgent (https://www.insidersoftware.com/font-managers/fontagent-mac/), and use it to activate legacy "suitcase"-format font files for widely-used fonts such as Helvetica, Times, Arial, etc. [List of other uplifts needed for the feature/fix]: none [Is the change risky?]: no [Why is the change risky/not risky?]: just adds a path to the sandbox rules [String changes made/needed]: none

yeah sorry, i had 2 users on irc reporting this where i don't have a way to reach out to them again and in the meantime no new similar reports came to my notice...

No worries... confirmation from real-world affected users would always be nice, but the nature of the problem (and the fix) is clear enough that I'm not really concerned about it. (The other thing to watch out for, though, is any similar reports where the users have a *different* font manager, which may need its own separate fix. We're trying to deal with them as we become aware of them, but until bug 1393259 is resolved there could still be others out there.)

Tracking for 57/58 to make sure we follow up.

Comment on attachment 8928511 [details] [diff] [review] Add the path used by FontAgent to the sandbox rules on macOS Fix a font rendering issue. Beta58+.

Comment on attachment 8928511 [details] [diff] [review] Add the path used by FontAgent to the sandbox rules on macOS Approval Request Comment [as for Beta, see comment 12] Given the trivial nature of this fix, and the severe brokenness for affected users, can we take this as a dot-release ridealong?

Comment on attachment 8928511 [details] [diff] [review] Add the path used by FontAgent to the sandbox rules on macOS I was writing a needinfo request to ask for this right now :) Taking it to fix a regression, trivial change!

I couldn't reproduce the initial issue under Mac OS X 10.13. I've installed FontAgent, activated Helvetica, Times New.. and Arial fonts and opened Firefox 57.0. Google.com, twitter.com or messenger.com had no fonts issues. Are there any intermediate steps between activating the fonts and using Firefox? Thank you!

Did you activate these fonts from legacy "suitcase"-format font files, as used on old versions of MacOS (not modern .otf / .ttf / .dfont files)? The issue here occurs specifically when the fonts are in files that don't have a recognized font-file extension on their name, which is commonly the case for the old "suitcase" resource format.

I couldn't reproduce and verify myself, but accordingly to the sumo posts related to this problem, this is now fixed in Firefox Quantum 57.0.2, so I'm removing the qe-verify+ flag.