1.73 MB, image/png
59 bytes, text/x-review-board-request
85.09 KB, image/png
1.28 MB, application/pdf
76.47 KB, image/png
75.65 KB, image/png
4.29 KB, patch
|Details | Diff | Splinter Review|
166.31 KB, text/plain
Assignee: nobody → haftandilian
Component: General → Security: Process Sandboxing
Priority: -- → P1
Product: Firefox → Core
(In reply to Meridel from comment #0) > Some fonts not displaying correctly in Release, Nightly, and Beta versions. > After changing security.sandbox.content.level to 1 and then restarting > browser, problem resolved. Meridel gave me some additional information offline: the machine is running 10.11.3 and Font Explorer X is used on the system with ~400 fonts installed in ~/FontExplorer X/Font Library/.
I reproduced this on Firefox 60 with 10.10 (and for now am assuming this is the same problem hit by Meridel on 10.11) and found that the call to CGFontCreateWithFontName() is not setting up the sandbox extension like it does on newer OS versions. This is a regression introduced by my fix for bug 1432567. As a short term fix we can re-introduce the sandbox whitelisting for fonts on the affected OS X versions. As a better fix, we could try having content processes synchronously request an extension for the font at the time the font loading fails. More debugging is needed to understand exactly what's going on here.
(In reply to Haik Aftandilian [:haik] from comment #2) > This is a regression introduced by my fix for bug 1432567. I meant bug 1393259. Bug 1432567 is a test I'm working on to catch regressions like this. The 10.10 failure I've been debugging on bug 1432567 is probably this exact problem.
we're also seeing reports about this from sumo user after the 60 update. it would be great if we could perhaps re-implement the workaround we had in place pre-60 for custom font directories in a potential dot release.
status-firefox60: --- → affected
status-firefox61: --- → affected
status-firefox62: --- → affected
status-firefox-esr52: --- → unaffected
status-firefox-esr60: --- → affected
tracking-firefox-esr60: --- → ?
Summary: Fonts not displaying with FontExplorer X fonts in Firefox 60 → Fonts not displaying with OS X 10.11 and Earlier with Font Managers
I've been able to reproduce the problem on 10.9 (Mavericks), 10.10 (Yosemite), and 10.11 (El Capitan). 10.12 (Sierra) and 10.13 (High Sierra) are not affected in all the testing I've done. I'll have a fix posted shortly.
Comment on attachment 8975903 [details] Bug 1460917 - Fonts not displaying with FontExplorer X fonts in Firefox 60 https://reviewboard.mozilla.org/r/244102/#review250144 ::: commit-message-13249:5 (Diff revision 1) > +Bug 1460917 - Fonts not displaying with FontExplorer X fonts in Firefox 60 > + > +Add back font whitelist rules for 10.11 and earlier to workaround > +sandbox font extensions not being issued on those OS versions. > + Since this is really just restoring some straight-forward lines removed from this patch , I guess I'm comfortable reviewing.  https://hg.mozilla.org/mozilla-central/diff/9218e87c25fb/security/sandbox/mac/SandboxPolicies.h
Attachment #8975903 - Flags: review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/373ddd2470ec Fonts not displaying with FontExplorer X fonts in Firefox 60 r=handyman
Status: NEW → RESOLVED
Last Resolved: 10 months ago
status-firefox62: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla62
Could you nominate this for uplift to beta and esr? Seems like something we should fix everywhere possible, given the severity of the breakage for affected users.
tracking-firefox60: --- → ?
tracking-firefox61: --- → +
tracking-firefox62: --- → +
Comment on attachment 8975903 [details] Bug 1460917 - Fonts not displaying with FontExplorer X fonts in Firefox 60 I think we need this fix in Release60 and ESR60, but I think it would make sense to land this on Beta first to allow a bit more time for users hitting the problem to verify it fixes their problem, in addition to the verifications already done. Approval Request Comment [Feature/Bug causing the regression]: Bug 1393259 - Remote access to fonts from custom directories, font managers [User impact if declined]: Mac users on OS X 10.11 and earlier (we support 10.9 and 10.10) using third party font managers are likely to experience broken font rendering making sites illegible. [Is this code covered by automated tests?]: No [Has the fix been verified in Nightly?]: The submitter verified the fix in Nightly on 10.11. I've verified the fix using a test case on 10.9, 10.10, 10.11 and also tested the fix on 10.12 and 10.13 where the problem was not reproducible. [Needs manual test from QE? If yes, steps to reproduce]: Use a third party font manager such as Font Explorer X Pro (configured to organize fonts) with a collection of fonts and verify font rendering works as expected on 10.11. [List of other uplifts needed for the feature/fix]: None [Is the change risky?]: No. It reintroduces old code and the changes are low risk. [Why is the change risky/not risky?]: The changes add whitelisted directories to the Mac content process sandbox and don't introduce new C++ code. The new code is only executed on Mac builds. And the changes only apply to Mac OS 10.11 and earlier. [String changes made/needed]: None
Comment on attachment 8975903 [details] Bug 1460917 - Fonts not displaying with FontExplorer X fonts in Firefox 60 If memory serves me correctly, this isn't the first time we've had breakage like this :(. Any way we can shore up our testing practices here to avoid shipping this again? Approved for 61.0b6 anyway, let's get more verification ahead of any release/esr60 consideration.
Attachment #8975903 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
status-firefox61: affected → fixed
I'm sorry to report that I came across another font-rendering issue when I performed a Google search. I can't seem to attach the screenshot here, unfortunately.
Could you check exactly what version of Firefox you're seeing that issue with? The "version" and "build ID" from Help/Troubleshooting Information will confirm this. Thanks! (To attach a new screenshot, see the "Attach File" link that appears immediately below the existing attachments, before all the bug comments.)
It looks like the affected content is the elements styled with font-weight:lighter. On a Mac with default fonts installed, I wouldn't expect that to have any effect on the rendering, as the text is using font-family:arial and Arial is generally available only in Regular and Bold weights. Do you have additional faces of Arial installed, such as an Arial Light or Thin face? Or do you not have Arial installed at all, but instead use Helvetica or Helvetica Neue?
These are the fonts I have installed!
We need to hold off on uplifting the fix to Release until the issue Meridel is seeing is resolved. I'm working on this.
(In reply to Meridel from comment #25) > Created attachment 8976639 [details] > Screen Shot 2018-05-17 at 11.47.03 AM.png Meridel, the date on that Nightly build is 2018-05-14. That version of Nightly doesn't have the fix yet. Can you try updating your Nightly to the most recent version? Clicking the "Restart to update Nightly" from the About Firefox dialog should do it. You may have to update more than once to get to the latest version.
I've tried to reproduce this issue on MacOS 10.11.6 using the 61.0b5 version but didn't managed to do so. Could you please provide more information regarding the fonts that you used? The issue is reproducible with all of your fonts added in the FontExplorer X app? Or only with some of them? I've installed the FontExplorer X app and added a font to it. Then I've selected that font in Firefox but couldn't reproduce the issue. There are extra steps that I need to do? Or if you have time, can you please test this issue on the new beta build 61.0b6 and confirm that the issue is fixed?
To reproduce this problem on 10.11 (and earlier OS X versions) with FontExplorer X, you need to import a font into FontExplorer such that it is copied to "~/FontExplorer X/Font Library". Selecting the font in FontExplorer and hitting Command-I will show details about the font including the path. Then you need to visit a page that uses the font. It must not be a file:// link, it must be a remote page. If you create a simple html page using the font, you can serve it up on localhost:8000 by running "python -m SimpleHTTPServer 8000" in Terminal from the directory with the html file.
I've managed to reproduce this issue on MacOS 10.11.6 using the 61.0b5 version. I couldn't reproduce the issue before because of the font that I've downloaded. Now I can confirm that the bug is fixed and verified on the 61.0b6 version. Also I've tested the issue on the Nightly build and it's fixed and verified. If you consider to uplift this issue to Release or ESR please contact me so I can test this and verify it.
status-firefox61: fixed → verified
status-firefox62: fixed → verified
tracking-firefox61: + → ---
tracking-firefox62: + → ---
I'm on Nighly, 62.0a1(In reply to Cristian Craciun from comment #28) > I've tried to reproduce this issue on MacOS 10.11.6 using the 61.0b5 version > but didn't managed to do so. Could you please provide more information > regarding the fonts that you used? The issue is reproducible with all of > your fonts added in the FontExplorer X app? Or only with some of them? > > I've installed the FontExplorer X app and added a font to it. Then I've > selected that font in Firefox but couldn't reproduce the issue. There are > extra steps that I need to do? > > Or if you have time, can you please test this issue on the new beta build > 61.0b6 and confirm that the issue is fixed? Looks like Haik responded to my NeedInfo. Please let me know if you need anything else from me.
Comment on attachment 8975903 [details] Bug 1460917 - Fonts not displaying with FontExplorer X fonts in Firefox 60 let's get this in for 60.1esr at least.
Attachment #8975903 - Flags: approval-mozilla-esr60? → approval-mozilla-esr60+
The issue Meridel hit with the fix described in comment 19 was due to an older version of Nightly being used. And Cristian reproduced and verified the problem with Beta. I feel confident we can uplift this to Release now. I'm close to landing a test for this with bug 1432567.
This is already on the radar for uplift to m-r if/when we do 60.0.2. There are no plans for that at this point.
This needs a rebased patch for release/esr60 uplift.
status-firefox-esr60: affected → fixed
Approved for 60.0.2.
status-firefox-esr60: fixed → affected
tracking-firefox60: ? → +
tracking-firefox-esr60: 61+ → 60+
Attachment #8975903 - Flags: approval-mozilla-release? → approval-mozilla-release+
status-firefox60: affected → fixed
status-firefox-esr60: affected → fixed
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:60.0) Gecko/20100101 Firefox/60.0 Build ID: 20180605201706 [ESR] User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:60.0) Gecko/20100101 Firefox/60.0 Build ID:20180605171542 Verified as fixed on the ESR 60.0.2 build and 60.0.2 release candidate build on MacOS 10.11.
Status: RESOLVED → VERIFIED
status-firefox60: fixed → verified
status-firefox-esr60: fixed → verified
Hey, just want to say that this issue also occurred with "Extensis Universal Type Manager" and still is after the latest patch.
(In reply to yannik.pier from comment #43) > Hey, > just want to say that this issue also occurred with "Extensis Universal Type > Manager" and still is after the latest patch. Yannik, could you confirm you're experiencing this problem with Firefox version 60.0.2 and report the version of OS X you are using? You can get the Firefox version number from the "Firefox->About Firefox" menu option. If you are still experiencing the problem, would you mind posting your system's font details? You can collect that data by using the Terminal app (/Applications/Utilities/Terminal) to run the following command. It will generate a file named FontList.txt on your desktop. If you could post that file as an attachment to this bug or email it to me, we can try to debug what's going wrong. system_profiler SPFontsDataType > ~/Desktop/FontList.txt
Yes, the issue occurs on 60.0.2 running on OS X 10.11, 10.12 is doing fine! This problem could also be caused by the way I need to handle fonts for my work, I closely deleted every font from the system to be able to load different versions of these fonts (printer business). Like this we are able to manage a lot more fonts in "Extensis Universal Type Manager" what would otherwise blocked by the system, stored get the fonts in cache folders: /Library/Extensis or ~/Library/Extensis FonList.txt is attached.
(In reply to yannik.pier from comment #45) > Created attachment 8985155 [details] > FontList.txt > > Yes, the issue occurs on 60.0.2 running on OS X 10.11, 10.12 is doing fine! > This problem could also be caused by the way I need to handle fonts for my > work, I closely deleted every font from the system to be able to load > different versions of these fonts (printer business). > Like this we are able to manage a lot more fonts in "Extensis Universal Type > Manager" what would otherwise blocked by the system, stored get the fonts in > cache folders: /Library/Extensis or ~/Library/Extensis > > FonList.txt is attached. Thanks for those details! As a workaround, you could use a directory ending in ".fontvault", for example ~/Library/Extensis.fontvault instead. This isn't a new problem and should be specific to OS X 10.11 and earlier. On 10.11 and earlier we are using whitelisted font paths for now (because our automatic font handling isn't working on those OS versions). I'll file a new bug to track this issue. It would be good to know if that avoids the problem for you. My understanding is that Extensis products normally add the .fontvault extension to default directory name or the name you specify for the font directory.
Great, thanks for the info! I will check if it is possible to redirect the vault location to a different folder. But as far as I know it's only possible to distinguish between ~/Library and /Library, I will check that with the Extensis support.
Sorry for the delay, the Extensis support is not the fastest ;-) But long story short, according to the support it's not possible to relocate the font vault of the UTC. Would it be possible to add the vault paths to the whitelist of Firefox?
(In reply to yannik.pier from comment #48) > Sorry for the delay, the Extensis support is not the fastest ;-) > But long story short, according to the support it's not possible to relocate > the font vault of the UTC. Thanks for following up. I was under the impression you had chosen that directory. > Would it be possible to add the vault paths to the whitelist of Firefox? Yes, I've filed bug 1469657 to address that.
You need to log in before you can comment on or make changes to this bug.