Proposal to remove some preferences override support

[Nicholas Nethercote]

Greetings,

In https://bugzilla.mozilla.org/show_bug.cgi?id=1413413 I am planning to
remove a couple of things relating to preferences.

1) Remove the defaults/preferences directory support for extensions. This
is a feature that was used by legacy extensions but is not used by
WebExtensions.

2) Remove the "preferences" override directory in the user profile.
This removes
support for profile preferences override files other than user.js.

The bug has a patch with r+. The specific things it removes include:
- The "load-extension-default" notification.
- The NS_EXT_PREFS_DEFAULTS_DIR_LIST/"ExtPrefDL" directory list, including
the entry from the toolkit directory service.

Does anybody foresee any problems with this change?

Thanks.

Nick

[Jörg Knobloch]

On 02/11/2017 00:41, Nicholas Nethercote wrote:

1) Remove the defaults/preferences directory support for extensions. This
is a feature that was used by legacy extensions but is not used by
WebExtensions.

Is that the facility that legacy extensions can have defaults/preferences/defaults.js to declare their preferences?

In Thunderbird we're trying to keep legacy extensions working, currently by having |ac_add_options "MOZ_ALLOW_LEGACY_EXTENSIONS=1"| in the mozconfigs.

So are the components legacy extensions rely on slowly dismantled? So some will keep working and some will stop working?

If so, what is the replacement? Setting up the preference in JS on the fly in the add-on?

Jörg.

[Kris Maglione]

On Thu, Nov 02, 2017 at 01:06:09AM +0100, Jörg Knobloch wrote:
> On 02/11/2017 00:41, Nicholas Nethercote wrote:
>
> 1) Remove the defaults/preferences directory support for extensions. This
> is a feature that was used by legacy extensions but is not used by
> WebExtensions.
>
> Is that the facility that legacy extensions can have
> defaults/preferences/defaults.js to declare their preferences?
>
> In Thunderbird we're trying to keep legacy extensions working, currently
> by having |ac_add_options "MOZ_ALLOW_LEGACY_EXTENSIONS=1"| in the
> mozconfigs.
>
> So are the components legacy extensions rely on slowly dismantled? So some
> will keep working and some will stop working?

Yes. The components that non-bootstrapped add-ons rely on,
anyway.

> If so, what is the replacement? Setting up the preference in JS on the fly
> in the add-on?

Yes.

[o.e....@gmail.com]

So what's the alternative for localized extension names and/or descriptions? At the moment I have these two lines in my defaults/preferences/defaults.js:

pref("extensions.{CC3C233D-6668-41bc-AAEB-F3A1D1D594F5}.name", "chrome://mailredirect/locale/mailredirect.properties");
pref("extensions.{CC3C233D-6668-41bc-AAEB-F3A1D1D594F5}.description", "chrome://mailredirect/locale/mailredirect.properties");

And chrome/locale/<localename>/mailredirect.properties contains the localized name/description:

extensions.{CC3C233D-6668-41bc-AAEB-F3A1D1D594F5}.name=Mail Redirect
extensions.{CC3C233D-6668-41bc-AAEB-F3A1D1D594F5}.description=Allow to redirect (a.k.a. "remail") mail messages to other recipients.

Maybe this can temporarily changed to a localized section in the extension's install manifest, but I suppose that functionality will go away too?

Onno

[Axel Hecht]

Looping in mkaply explicitly, if that has impact on organizational
deployments.

Axel

Am 02.11.17 um 00:41 schrieb Nicholas Nethercote: