use a "fonts" subdir for any locally-added fonts stored in the profile

RESOLVED FIXED in Firefox 19

Status

()

defect
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: jfkthame, Assigned: jfkthame)

Tracking

unspecified
mozilla20
ARM
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox18 wontfix, firefox19 fixed, firefox20 fixed)

Details

Attachments

(1 attachment)

Posted patch patch v1Splinter Review
In bug 619521, as part of preparation for "download-on-demand" fonts for additional languages, we added code to FT2FontList that will load any font files found in the current profile, in addition to fonts from the standard system fonts directory. Although we don't have all the infrastructure for download-on-demand in place yet, it is already posssible (as Mathieu notes in bug 619521 comment 64) for an add-on to provide extra fonts by putting them into the user's profile.

However, as noted in that comment, it would be cleaner to store such "local" fonts in a specific fonts subdirectory, rather than just dumping them in the top level of the profile.

We should make this change sooner rather than later, before people start deploying lots of font-installing add-ons that assume they can just put fonts directly into the profile dir.
Attachment #692652 - Flags: review?(blassey.bugs)
Jonathan, glad this is being considered. 

When moving to a dedicated directory, would it be possible to attach an "observer" to it so that when new fonts are copied/moved into the directory, Firefox automatically update its font list to include new one(s)?

It'd improve user experience surrounding this a great lot. 

Moreover, it seems it'd be a needed requirement since, as of Firefox Android v20, the Quite menu item has been removed (see bug 800071). There is therefore no way to trigger a restart of Firefox anymore. That's hugely problematic. If the above can't be done, I'd lobby for bug 800071 to be reverted.
Attachment #692652 - Flags: review?(blassey.bugs) → review+
(In reply to Mathieu Pellerin from comment #1)
> When moving to a dedicated directory, would it be possible to attach an
> "observer" to it so that when new fonts are copied/moved into the directory,
> Firefox automatically update its font list to include new one(s)?

I don't know if we have a directory-watching mechanism in Gecko that would facilitate this, though I can see why it'd be helpful. Maybe worth filing a separate bug for that.

(Note that if we get all of bug 619521 finished sometime, that will include a support for a "notification" that a font add-on could presumably use to request rebuilding the font list. Not quite as automatic as a directory observer, but it would provide a possible solution.)
(In reply to Jonathan Kew (:jfkthame) from comment #2)
> (Note that if we get all of bug 619521 finished sometime, that will include
> a support for a "notification" that a font add-on could presumably use to
> request rebuilding the font list. Not quite as automatic as a directory
> observer, but it would provide a possible solution.)

Jonathan, I relying on the notification your referring to to rebuild the font list might be problematic (i.e. in most cases, it'll trigger a useless rebuilding as no new fonts will be present). 

The two best options - IMO - are: #1, automatic rebuilding upon addition of fonts in a specific directory, or #2, coming up with a chrome function that can be called upon add-on installation to trigger a rebuilding.

#1 might be opening a door for abuse. I.e. what would happen is a third-party would flood the font directory with new fonts to get firefox into constantly rebuilding font list, effectively slowing down the browser experience.

#2 is probably safer, and relies on all the security features / behaviors of add-on offering and reviews.
Oh forgot to mention, if the proposal in this bug is agreed upon, it should be back-ported to v19 (currently Aurora) as to avoid having the feature introduced in v19 using one directory, only to change in v20.
(In reply to Mathieu Pellerin from comment #3)
> Jonathan, I relying on the notification your referring to to rebuild the
> font list might be problematic (i.e. in most cases, it'll trigger a useless
> rebuilding as no new fonts will be present). 

No, I didn't mean the notification sent by layout to say "we want a font for (xxx) script", but the "update-font-list" notification from part 3 there, which is what the front-end code would issue to say "we've added a font, now rebuild the font list". An add-on could issue that same notification after installing new fonts in the profile/fonts directory, to tell gecko to rebuild its list.

> The two best options - IMO - are: #1, automatic rebuilding upon addition of
> fonts in a specific directory, or #2, coming up with a chrome function that
> can be called upon add-on installation to trigger a rebuilding.

In other words, your #2 here would be served by the add-on firing an "update-font-list" notification. (Once the core code is in place to listen for such a notification, of course.)

> #1 might be opening a door for abuse. I.e. what would happen is a
> third-party would flood the font directory with new fonts to get firefox
> into constantly rebuilding font list, effectively slowing down the browser
> experience.

If a third-party has the ability to flood the font directory (or any other part of the profile) with files without the user's consent, I think we have more serious problems already!
https://hg.mozilla.org/mozilla-central/rev/3d464fe9bd01
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Comment on attachment 692652 [details] [diff] [review]
patch v1

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Adjustment to feature from bug 619521, landed in support of bug 785291.

User impact if declined: Add-on authors may wish to use this feature to provide extra fonts for Android users; by uplifting this patch, we'll reduce the confusion caused by later changing the place where they need to install such fonts.

Testing completed (on m-c, etc.): Landed on m-c, no issues encountered. (Not actually used in default configuration, only if fonts are added to the user's profile.)

Risk to taking this patch (and alternatives if risky): Minimal risk. We're not currently relying on the feature of loading fonts from the profile, so the change has no impact except for add-on authors who want to use this mechanism.

String or UUID changes made by this patch: none.
Attachment #692652 - Flags: approval-mozilla-beta?
Attachment #692652 - Flags: approval-mozilla-aurora?
Comment on attachment 692652 [details] [diff] [review]
patch v1

Sadly, we're in our final beta. Mobile add-on authors will have to wait till FF19 is released to use this feature.
Attachment #692652 - Flags: approval-mozilla-beta?
Attachment #692652 - Flags: approval-mozilla-beta-
Attachment #692652 - Flags: approval-mozilla-aurora?
Attachment #692652 - Flags: approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.