Closed Bug 765700 Opened 12 years ago Closed 12 years ago

newly-installed/activated fonts are not immediately available in Gecko

Categories

(Core :: Graphics: Text, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla20

People

(Reporter: jfkthame, Assigned: jfkthame)

Details

Attachments

(2 files, 1 obsolete file)

Although we have code in gfxMacPlatformFontList to receive notifications from ATS when the set of installed fonts is modified, the newly-installed font does not actually get used immediately.

STR:
- Ensure there is no font installed that supports the Ugaritic range (U+10380..1039F), or deactivate all such fonts in Font Book.
- Open http://alanwood.net/unicode/ugaritic.html, and see that the Ugaritic characters display as hexboxes.
- While this page is open, install (or activate) the MPH 2B Damase font from http://www.dafont.com/mph-2b-damase.font.
- Note that the hexboxes do not change. Refreshing or zooming the page doesn't help.
- Quit and restart the browser, and note that the Ugaritic characters now display as expected.

The problem seems to be that although we detect the ATS notification and rebuild the platform font list, this isn't sufficient to refresh the browser window: we have cached fonts, shaped words, text runs, etc.

As the PresContext already watches for modifications to the gfx.font_rendering.* prefs, where changes may invalidate any existing textruns and require reflow, we can handle this case as well by making a modification to an additional preference under this branch. The attached patch causes the newly-installed/activated font to immediately appear in the page, without requiring a browser restart (or even a page reload).

While this prefs-based approach may in principle be slightly less efficient than a more direct notification of some kind, updates to the list of installed fonts are not likely to be high-frequency events, so it doesn't seem worth creating a new mechanism just to handle this; piggy-backing on the existing pref-watching provides a simple solution.
Attachment #633999 - Flags: review?(jdaggett)
Hmm, I remembered we already have font.internaluseonly.changed on Windows, which is toggled in response to an update of the available fonts there; might as well use the same "internal" preference name here on OS X.

In testing, I've noticed that if I repeatedly activate and deactivate the _same_ font using Font Book, sometimes OS X doesn't bump the ATS font generation, and in this case, we don't rebuild the font list (because of the generation check in gfxMacPlatformFontList::InitFontList). A workaround if this happens is to deactivate and reactivate some other font, to trigger a generation update and hence rebuild the font list.
Assignee: nobody → jfkthame
Attachment #633999 - Attachment is obsolete: true
Attachment #633999 - Flags: review?(jdaggett)
Attachment #634021 - Flags: review?(jdaggett)
There's also a problem with the Windows version of this feature: widget/windows/nsWindow.cpp includes code to receive the WM_FONTCHANGE message and rebuild the list, but it only calls ForceFontUpdate (to trigger reflow, etc) if the font list reports that a new langGroup was found. This is wrong; we should always reflow when fonts are added, as the newly-installed fonts may be used by CSS even if they didn't add coverage for new languages.
Attachment #634023 - Flags: review?(jdaggett)
Attachment #634023 - Attachment description: part 2 - always rebuild the windows font list when fonts are added, not only if there's a new langGroup → part 2 - always trigger reflow when fonts are added on Windows, not only if there's a new langGroup
jdaggett, review ping?
jdaggett: ping?
Comment on attachment 634023 [details] [diff] [review]
part 2 - always trigger reflow when fonts are added on Windows, not only if there's a new langGroup

So if we're going to touch this code we should probably fix bug 628917 which has been hanging around for a while and is a more serious problem (I didn't confirm that it is but I'm guessing from the code that nothing has changed!).  Under Windows we update the font list once for every window...
Comment on attachment 634021 [details] [diff] [review]
patch v2, trigger PresContext to reflow when font list is updated

Seems fine I guess.  But given that we have dumped 10.5, we need to drop ATS to avoid all these weird ATS band-aids.  CTFontManager, available on 10.6, looks like the proper replacement.

https://developer.apple.com/library/mac/#documentation/Carbon/Reference/CoreText_FontManager_Ref/Reference/reference.html
Attachment #634021 - Flags: review?(jdaggett) → review+
(In reply to John Daggett - out until 27 Dec (:jtd) from comment #5)
> Comment on attachment 634023 [details] [diff] [review]
> part 2 - always trigger reflow when fonts are added on Windows, not only if
> there's a new langGroup
> 
> So if we're going to touch this code we should probably fix bug 628917 which
> has been hanging around for a while and is a more serious problem (I didn't
> confirm that it is but I'm guessing from the code that nothing has
> changed!).  Under Windows we update the font list once for every window...

That's a distinct issue IMO (it's a minor inefficiency, whereas this is incorrect behavior), but I went ahead and posted a patch there anyway.
Attachment #634023 - Flags: review?(jdaggett) → review+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: