Closed Bug 567552 Opened 14 years ago Closed 13 years ago

Non-installed fonts (on external drive, downloaded, etc) are activated by Firefox, and preference to not ask again is ignored

Categories

(Core :: Layout: Text and Fonts, defect)

Product:
Core
Component:
Layout: Text and Fonts
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- -
status2.0 --- wanted

People

(Reporter: mikes, Assigned: jtd)

References

Details

(Whiteboard: [sg:moderate])

Attachments

(3 files, 1 obsolete file)

jesse's insane screenshot
199.00 KB, image/png
Details
partially-reduced testcase to trigger the bug on jesse's laptop
339 bytes, text/html
Details
patch v2, disable font auto-activation at startup using CTFontManager API
1.64 KB, patch
jaas
: review+
jfkthame
: feedback-
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.55 Safari/533.4
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3

When opening firefox, and going to any page, fonts on an external drive are requested to be loaded. Clicking the Allow button proceeds to the next font. Checking the "Don't not ask me again for Firefox.app" tickbox has no effect the next time Firefox is loaded.

Reproducible: Always

Steps to Reproduce:
1.Open Firefox.
2.Load a page
Actual Results:  
Dialog pops up: Firefox.app want to use the font "FontName" on the volume "HardDrive". This font is not installed. Allow Firefox.app to use this font? Happens for all fonts on an external drive.

Expected Results:  
Surprised that it asked to use it at all. But did expect the "Don't ask me again" setting to be retained.

other examples, with links to screenshots:
http://support.mozilla.com/nl/forum/1/625704
http://forums.mozillazine.org/viewtopic.php?f=38&t=1184825&start=0&st=0&sk=t&sd=a
Component: Preferences → Layout: Text
Product: Firefox → Core
QA Contact: preferences → layout.fonts-and-text
That's an OS-level dialog, no?  As in, it's your OS that's deciding to forget that you told it to not ask again, not us...
It's also mentioned in bug 548111 - you can switch off automatic font activation. Apparently, the OS remembers that it has seen the font somewhere (in case of the mozillazine.org thread, on an unlikely partition). Is it not possible to remove this memory (reset all the font settings ?)
You're seeing the "auto activation" feature which was introduced in 10.5, fonts found in random places on hard drives will get picked up.  When a document tries to use one, the system will prompt the user about whether to enable or not.

To disable this feature:

1. Run FontBook
2. FontBook menu > Preferences
3. Disable "Automatic font activation"

It looks like this can be disabled by the app via a 10.6-specific CTFontManager call:

http://developer.apple.com/mac/library/documentation/Carbon/Reference/CoreText_FontManager_Ref/Reference/reference.html#//apple_ref/c/func/CTFontManagerSetAutoActivationSetting

If this happens at startup, maybe ATS is trying to auto-activate fonts active in the past?  Argh...
I guess the font might be mentioned somewhere, maybe as one of the choices in Tools->Options->Content->Fonts & colors ? mikes@freestanding.net : maybe you see something in about:config (type that in te location bar, press enter and filter with 'font') ? If one of the lines is printed in bold, it was changed from the default.

What would be the result if Firefox started to use the CTFontManagerSetAutoActivationSetting() system call, and one of those fonts needed to be loaded ? I think that it would still be loaded when the application starts up, and CTFontManagerSetAutoActivationSetting() would be of no use. The problem here seems to be that the preference is not remembered at all for some reason.
(In reply to comment #4)
> What would be the result if Firefox started to use the
> CTFontManagerSetAutoActivationSetting() system call, and one of those fonts
> needed to be loaded ? I think that it would still be loaded when the
> application starts up, and CTFontManagerSetAutoActivationSetting() would be of
> no use. The problem here seems to be that the preference is not remembered at
> all for some reason.

I think one possible solution would be simply to disable it via the 10.6 API before ever calling other font API's.  We could add a pref to allow it to be enabled if someone really desires this feature.  In general, I think the UI portion of this system feature is far more troublesome than it's worth, it just annoys most users.
(In reply to comment #3)

> If this happens at startup, maybe ATS is trying to auto-activate fonts active
> in the past?  Argh...

On #camino, we just had a user report the same issue with nightly Camino builds (gecko 1.9.2 based). At start-up. In this case the font was actually installed in ~/library/fonts.
Hi, I'm the user that the previous comment mentioned on #camino.  I've still got the problem with nightlies.  Disabling "Automatic font activation" doesn't fix the problem.  Looking under about:config the only thing after filtering for fonts which isn't default setup is: print.print_downloadfonts
No idea what that means.  It is starting to get annoying having that pop up box come up every time I start Camino
Just an update.
Upgrading from OS 10.6.3 to 10.6.4 seems to fix the problem of "Don't ask me again" not working.  The message no longer appears when I start up Camino, however the program isn't responsive for some time and the external hard drive spins up so I'm assuming the problem is still ongoing (just don't get the annoying popup box anymore)
I am on 10.6.4 and it persists
Status: UNCONFIRMED → NEW
Ever confirmed: true
This happens to me persistently on 10.6 even without an external drive.  No matter what the setting in FontBook dialog, the user is prompted to access miscellaneous fonts in various non-system folders (i.e. fonts that I have lying around, inactive, in folders on my Desktop).

This is absolutely an OS bug but I really think we need to work around it, possibly using the 10.6 specific API's to tell the OSX to shaddup via the API noted in comment 3 for example.
blocking2.0: --- → ?
The fact that on the MacBook Pro, 10.6.4, where this was a problem, had the fonts installed on it that were being requested, caused me to wonder if firefox was looking at "computer" fonts or "user" fonts. Using FontBook, I disabled the auto-activate fonts "feature" and moved all of the unique "user" fonts to "computer" fonts, deleting duplicates, until all of the fonts are now "computer" fonts, with no "user" fonts. When I clicked back to firefox, still open, all of the text on the page had disappeared, causing me to think it has been using "user" fonts, and ignoring the "computer" fonts, unless the fonts were on a remote drive, as prompted by the mac font mgr. Refreshing did not restore the fonts to firefox, but quitting and restarting did. It is no longer asking to allow fonts on an external drive.
(In reply to comment #3)
> To disable this feature:
> 
> 1. Run FontBook
> 2. FontBook menu > Preferences
> 3. Disable "Automatic font activation"

I'm getting this message now in Firefox 3.6.13 after my Macbook with Filevault froze and I did a hard power down to recover it. When I logged back in, I started getting the "Firefox.app wants to use the font "Name Here" on the volume "name of my filevault".

I ran disk permissions repair through Disk Utility, tried the font activation preference in Font Book, and tried upgrading to Firefox 4 beta 7. None of those made a difference. Since I have a couple hundred fonts, this bug basically makes Firefox unusable to me until I figure out some workaround.
I jumped right to being drastic and removed the following and the problem resolved after re-installing the 3.6.13 .app. The Font Book alternate preference is still in place as well.

* ~/Library/Application Support/Firefox
* ~/Library/Caches/Firefox
* ~/Library/Preferences/org.mozilla.firefox.plist
* and Firefox.growlTicket (don't remember the path)

Note, just removing the files didn't work. I had to reboot as well.

The concluding resolution was some combination of disk permissions repair, font preferences, Firefox preferences nuke, and rebooting (again) in Mac OS 10.6.5.
I signed up today just to contribute to this thread.  I have been having this problem for over two weeks on my iMac 2.8 GHz Intel Core 2 Duo.  I am running FF 3.6.12 and Thunderbird 3.1.  I mention Thunderbird, because the persistent request to install fonts occurs on both apps, not just FF.

The odd thing is the requests in both apps want to install on the volume "NEON," which is my SuperDuper (bootable) backup drive, and should contain all the fonts that are on my boot drive.

I have tried the tricks suggested for FontBook, with no change in behavior.  With some difficulty, I did install the fonts being asked for on both volumes, with the result that Firefox and Thunderbird began asking to install a new set of completely different fonts, although fewer in number that when the problem began.

This is now beyond annoying.
(In reply to comment #12)
> This is absolutely an OS bug but I really think we need to work around it,
> possibly using the 10.6 specific API's to tell the OSX to shaddup via the API
> noted in comment 3 for example.

John, any updates on this?  I assume it's not fixed in 10.6.6 and hasn't been rdar://ed, and I still hear from people that it affects regularly—always in a terribly painful manner.
Has anyone tried the method I suggested in comment #13? Move all unique user fonts to computer fonts and then delete all the user fonts? It's been 6 months and I've never had another issue with it, and I didn't have to screw around with fonts on external volumes, either, as long as there was a copy in computer fonts on the boot drive. This leads me to believe it may not be entirely a Mac OS problem if there is a way for apps to distinguish between computer fonts and user fonts. - Mac programmer since 1987.
(In reply to comment #18)
> Has anyone tried the method I suggested in comment #13? Move all unique user
> fonts to computer fonts and then delete all the user fonts? It's been 6 months
> and I've never had another issue with it, and I didn't have to screw around
> with fonts on external volumes, either, as long as there was a copy in computer
> fonts on the boot drive. This leads me to believe it may not be entirely a Mac
> OS problem if there is a way for apps to distinguish between computer fonts and
> user fonts. - Mac programmer since 1987.

I apologize for not mentioning this in my earlier comment (#16).  That was the FIRST thing I did to attempt a remedy.

I have NOT YET found the courage to try the method suggested in # 15, ie;

* ~/Library/Application Support/Firefox
* ~/Library/Caches/Firefox
* ~/Library/Preferences/org.mozilla.firefox.plist
* and Firefox.growlTicket (don't remember the path)
This happened to me again with Thunderbird. So far, I have deleted

~/Library/Thunderbird
~/Library/Caches/Thunderbird
~/Library/Preferences/org.mozilla.miramar.plist

and executed /Applications/Miramar.app/Contents/MacOS/thunderbird-bin -safe-mode to disable all addons. None of that has fixed it.
Sorry, posted too soon. I restored ~/Library/Thunderbird, but left the cache and plist files in the trash and rebooted. After the reboot, the font prompt didn't return. Deleting only those two kept my account information in-tact.

I don't know if it's related or not, but I didn't get this error until after I ran fennec 4.0 on my Mac.
I hit this dialog when I loaded http://vulu.net/the-physics-of-portals. I guess the OS decided that gfx/tests/crashtests/580719-bad_head_table.ttf matched a font name used in the page.
This is probably a security hole. I'm guessing that web pages can cause this to happen, and that fonts loaded in this manner probably do not go through the same sanitization that web fonts go through (see bug 527276).
Whiteboard: [sg:moderate]
(In reply to comment #22)
> Created attachment 528281 [details]
> jesse's insane screenshot
> 
> I hit this dialog when I loaded http://vulu.net/the-physics-of-portals. I guess
> the OS decided that gfx/tests/crashtests/580719-bad_head_table.ttf matched a
> font name used in the page.

Indeed it does: 580719-bad_head_table.ttf is a (slightly-munged, I guess) copy of OFL Sorts Mill Goudy TT.

If the Font Book pref to turn off automatic font activation isn't working, this seems to be an OS bug.

I think our best chance of working around this is probably to rewrite gfxMacPlatformFontList::LookupLocalFont so that it does not use ATSFontFindFromPostScriptName and ATSFontFindFromName, as these must be the APIs that are incorrectly ignoring the preference.

This should probably be part of a general migration from ATS to CT APIs in gfxMacPlatformFontList. Might be tricky, though, as CT does weird things with some of the font tables we refer to, returning its own synthetic versions instead of the real table from the font.
This problem has come back for me.  Solved it before with the changes to preferences in FontBook.  Those haven't changed, but now the problem is back!  I'm running Firefox 4.01 and Mac OS 10.6.7 on a MacBook with a 2.26 GHz Intel processor.  Help!  I'm at my wits end and am ready to quit using Firefox!
Happened again today for me with a Miramar nightly. I don't think it was the specific nightly that had a build problem cause when I rebooted, without having deleted configs as I've done before, the problem went away. Maybe my filevault just didn't mount correctly on in these cases? I'm still making wild guesses.
Guessing this will do the trick:

CTFontManagerSetAutoActivationSetting(NULL, kCTFontManagerAutoActivationDisabled);

This is a 10.6-only call so we'll need to use weak-linked function.
What's 10.6-only, the bug or the function that turns off the bug?
(In reply to comment #29)
> What's 10.6-only, the bug or the function that turns off the bug?

Both.  I haven't heard of this happening on 10.5.  The API to turn off auto-activation per-app is a 10.6-only API.
The code is functional but I can't reproduce the testcase right now.  Jesse, it would be interesting to see if this solves the problem (i.e. without changing the default auto-activation settings via FontBook).
This patch fixes the problem for me :)
I am not as tech savvy.  How to I use/insert this patch?
(In reply to comment #35)
> I am not as tech savvy.  How to I use/insert this patch?

I ran a tryserver build with the patch.  You can download the build here:

  http://bit.ly/mEUkxW

Please let me know if this fixes the problem for you.
Hallelujah!  That did the trick.  Thank you!
Just to be clear, do NOT continue using the tryserver build.  It will not receive security updates.
So, if I run the tryserver build, the problem goes away. When I restart Firefox I still have the problem.  Will this go away with the next release?
At a guess, this bug will be fixed in Firefox 6 (to be released in August).  Depends on whether there are any issues with the patch.
John, is that patch ready for review?
I was able to reproduce this bug on a machine with multiple drives containing a mozilla build environment on each.  In that configuration, Jesse's testcase causes the prompt to appear.  The patch fixes it but unfortunately it appears to affect the *global* setting, even though the documentation says passing NULL should only affect the current bundle.

Steps to show this:

1. Set auto font activation settings in FontBook (Font Book menu > Preferences..., select "Auto Font Activation" and "Ask me before activating".
2. Quit FontBook
3. Run tryserver build
4. Run FontBook again to confirm that global settings have been cleared

CTFontManager (only on 10.6):
http://developer.apple.com/library/mac/documentation/Carbon/Reference/CoreText_FontManager_Ref/Reference/reference.html#//apple_ref/c/func/CTFontManagerSetAutoActivationSetting

I'm going to add code to the patch to explicitly fetch the app bundle identifier, as is done in nsLocalFile::GetBundleIdentifier:

http://mxr.mozilla.org/mozilla-central/source/xpcom/io/nsLocalFileUnix.cpp#2364
(In reply to comment #39)
> So, if I run the tryserver build, the problem goes away. When I restart Firefox
> I still have the problem.  Will this go away with the next release?

Does disabling auto font activation not work for you (see comment 3)?  That's effectively what the tryserver build is doing.
(In reply to comment #43)
> (In reply to comment #39)
> > So, if I run the tryserver build, the problem goes away. When I restart Firefox
> > I still have the problem.  Will this go away with the next release?
> 
> Does disabling auto font activation not work for you (see comment 3)?  That's
> effectively what the tryserver build is doing.

I've seen this issue on someone else machine [**] (it started shortly after the 10.6.7 update). At Camino/Fx4 startup the dialog popped up - asking for Myriad Pro (in /Library/application support/Adobe/something-or-other... - cs5 installed) [*]. That dialog had a checkbox of the type 'don't ask again for _this_ application' (from memory...). Checking that made the problem go away for both Camino and Fx 4.
(the Font Book prefs were not changed, no other app ever asked for fonts this way)


[*] Myriad Pro also installed in /Library/Fonts, where adobes crappy installer puts it

[**] that person had done some font-cache cleaning shortly before upgrading to 10.6.7, including tossing away com.apple.ATS.plist
Use CFBundle API's to get the current bundle identifier and pass that into the CTFontManager call to disable font auto-activation (auto-annoyance?).  Confirmed that this fixes the problem without affecting the global auto-activation setting.
Attachment #529985 - Attachment is obsolete: true
Attachment #530527 - Flags: review?(joshmoz)
Attachment #530527 - Flags: feedback?(jfkthame)
New tryserver build here using patch v2:

http://people.mozilla.org/~jdaggett/bugs/567552/trybuild

As Boris points out, this is just for testing, once the fix lands it will be available in nightly builds and then in general releases once it's gone through a release cycle.  I'll probably pull the build in a week or so (or earlier if this is landed).
Comment on attachment 530527 [details] [diff] [review]
patch v2, disable font auto-activation at startup using CTFontManager API

It's good to know that this can fix the (highly annoying!) behavior. However, I'm uneasy about simply turning the feature off unconditionally, as this patch currently does. It is after all an OS "feature" that Apple presumably believes can be useful/appreciated, and it's intended (judging by the Font Book UI) to be under the user's control.

In addition, I'm concerned that there may be font management utilities that will be adversely affected if we override this - I'm thinking of things like Suitcase or Font Explorer that may depend on hooking in to system font APIs. I haven't done any testing of such tools, however.

One possibility might be to add a preference, so that it is possible for users to "opt out" of this override if they want the system behavior to remain unchanged.
Attachment #530527 - Flags: feedback?(jfkthame) → feedback-
I don't care if Apple thinks it's useful. With web pages able to add files to your fs in various ways and select which fonts Firefox tries to use, it's a security hole and an annoyance.
But the override would have to be the default.   In the case of hitting the problem with a large number of fonts the user would have to clear potentially hundreds of blocking dialogs before getting to the point where it's possible to type about:config into the address bar.  I've seen it (sporadically) when loading up zips of the Google Web Font set.  That requires clearing 173 dialogs before you can do anything.
(In reply to comment #47)

> It's good to know that this can fix the (highly annoying!)
> behavior. However, I'm uneasy about simply turning the feature
> off unconditionally, as this patch currently does. It is after
> all an OS "feature" that Apple presumably believes can be
> useful/appreciated, and it's intended (judging by the Font Book
> UI) to be under the user's control.

I think in this case we're dealing with a feature that seems to
have a buggy/partial implementation.  After all, many users have
reported this behavior arising in unpredictable situations,
possibly related to the prescence of an external hard drive (I
can't reproduce the bug on my home iMac but can on my work Mini,
both running the same update of 10.6). I can't reproduce the
buggy behavior on 10.5.

> In addition, I'm concerned that there may be font management
> utilities that will be adversely affected if we override this -
> I'm thinking of things like Suitcase or Font Explorer that may
> depend on hooking in to system font APIs. I haven't done any
> testing of such tools, however.

Hmm, this doesn't seem logical, the patch disables font
"auto-activation" by the OS *only* for Firefox, not globally. It
does not disable auto-font activation by other applications, nor
does it disable font activation in general.  We still handle
updates to the set of active fonts, so I don't see how font
management utilities would be affected. Playing around with
FontBook, I haven't run into any problems activating/deactivating
fonts.

> One possibility might be to add a preference, so that it is
> possible for users to "opt out" of this override if they want
> the system behavior to remain unchanged.

So if there was a pref set to "disable font auto-activation" by
default, you would be okay with the patch?

I agree that disabling OS prefs in general is not a good thing
but I think in this case we can't fix the underlying flakey/buggy
behavior so I think it's reasonable to work around the problem.
(In reply to comment #50)
> So if there was a pref set to "disable font auto-activation" by
> default, you would be okay with the patch?

Yes, that would be better, IMO. I understand this can be a huge nuisance for some people, so working around it seems like a good idea. I just think we ought to provide a way that users can restore the default OS behavior if they want it, for whatever reason.
To be honest, I don't think it's worth providing hidden prefs like that. Very few users will ever find it and use it.

In this case, the OS has a feature that's unreliable to the point of being unusable, so we're disabling it. That's nothing new.
Comment on attachment 530527 [details] [diff] [review]
patch v2, disable font auto-activation at startup using CTFontManager API

Review of attachment 530527 [details] [diff] [review]:
-----------------------------------------------------------------
Attachment #530527 - Flags: review?(joshmoz) → review+
Assignee: nobody → jdaggett
I don't know if it is related, but now my Microsoft Word document is asking for font usage on my back up drive....
Based on discussions with roc related to comment 51 and comment 52, I've gone ahead and landed this on trunk:
http://hg.mozilla.org/mozilla-central/rev/7f325307387d

If it turns out that there's a situation where a pref to control this is necessary, I'll write up a follow-on patch.  If Apple fixes the underlying problem in a future OS release, we can restrict when auto font activation is disabled to releases prior to the fix release.
(In reply to comment #54)
> I don't know if it is related, but now my Microsoft Word document is asking
> for font usage on my back up drive....

Right, these seem to be the conditions to reproduce the OS bug, namely fonts on an external drive and an app using older font APIs (I don't know that Word is but I think it's certainly possible).
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Summary: Fonts on External drive are activated by Firefox, and preference to not ask again is ignored → Non-installed fonts (on external drive, downloaded, etc) are activated by Firefox, and preference to not ask again is ignored
fwiw, I could finally reproduce this on one of my systems (10.6.7, with NO external HD attached)
At start up, Aurora (1st time launch) asked for Myriad Pro (CS 5), located in
/Library/Application Support/Adobe/PDFL/9.9/Fonts
(Myriad Pro _is_ installed in /Library/Fonts)

Checking that checkbox in the dialog box writes to com.apple.ATS.plist
<key>org.mozilla.aurora</key>
<string>ATSAutoActivationDisable</string>
Depends on: 659182
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: