Fwd: Re: Proposal to remove some preferences override support
Some light reading :-(
-------- Forwarded Message -------- Subject: Re: Proposal to remove some preferences override support Date: Wed, 1 Nov 2017 17:08:10 -0700 From: Kris Maglione <kmaglione@mozilla.com> To: Jörg Knobloch <jorgk@jorgk.com> CC: dev-platform@lists.mozilla.org
On Thu, Nov 02, 2017 at 01:06:09AM +0100, Jörg Knobloch wrote:
On 02/11/2017 00:41, Nicholas Nethercote wrote:
- 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.
That will cause massive breakage.
I suggest we should keep this patch, for our build of Gecko.
Jörg Knobloch wrote on 02.11.17 01:14:
Some light reading :-(
-------- Forwarded Message --------
Subject: Re: Proposal to remove some preferences override support
Date: Wed, 1 Nov 2017 17:08:10 -0700
From: Kris Maglione kmaglione@mozilla.com
To: Jörg Knobloch jorgk@jorgk.com
CC: dev-platform@lists.mozilla.org
On Thu, Nov 02, 2017 at 01:06:09AM +0100, Jörg Knobloch wrote:
On 02/11/2017 00:41, Nicholas Nethercote wrote:
- 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.
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
On 02.11.17 01:14, Jörg Knobloch wrote:
Some light reading :-(
-------- Forwarded Message --------
Subject: Re: Proposal to remove some preferences override support
Date: Wed, 1 Nov 2017 17:08:10 -0700
From: Kris Maglione kmaglione@mozilla.com
To: Jörg Knobloch jorgk@jorgk.com
CC: dev-platform@lists.mozilla.org
On Thu, Nov 02, 2017 at 01:06:09AM +0100, Jörg Knobloch wrote:
On 02/11/2017 00:41, Nicholas Nethercote wrote:
- 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.
Any idea about the time frame of this change? This will require quite
some changes for "legcy" add-ons.
-Patrick
On 02/11/2017 14:38, Ben Bucksch wrote:
That will cause massive breakage.
Will it? It affects add-ons that define preferences that way. Looking at the add-ons I wrote, there's one affected which can be fixed by creating the preference on the fly.
I suggest we should keep this patch, for our build of Gecko.
I don't understand that sentence.
Jörg.
Jörg Knobloch wrote on 02.11.17 15:15:
On 02/11/2017 14:38, Ben Bucksch wrote:
That will cause massive breakage.
Will it? It affects add-ons that define preferences that way. Looking
at the add-ons I wrote, there's one affected which can be fixed by
creating the preference on the fly.
It will break most extensions that I know.
The extension often queries preferences, and presumes that the
preference is there. If neither a user pref is set, not a default pref,
nor a hardcoded default, then the pref UI throws an exception and the
extension is broken. Hardcoding is bad coding practice. The developer
relies on the preference being there, so the extension was never tested
with the default prefs missing. Errors can happen at any place in the
extension code, anywhere prefs are queried. So, you'd need to exercize
all code paths, or make a static code inspection, to verify that the
extension doesn't break.
For illustration purposes only, try removing thunderbird.js and all
other default prefs from Thunderbird, and try running it. Then try
fixing all breakage.
Also, about:config will be broken, because users want to see the
preferences that are available (even if they didn't change them yet).
Ben
I suggest we should keep this patch, for our build of Gecko.
I don't understand that sentence.
Jörg.
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
On 02/11/2017 15:04, Patrick Brunschwig wrote:
<pre class="moz-quote-pre" wrap="">Any idea about the time frame of this change? This will require quite some changes for "legcy" add-ons.
Please refer to the attached article from dev-platform.
GRRR, can't attach an .eml on this mailing list due to some overzealous virus checker. Read it here instead:
https://groups.google.com/d/msg/mozilla.dev.platform/MKFvSI21OCE/xSTY5lCrAwAJ
If I understand it correctly, it will land in Daily sometime in the very close future, certainly before mozilla59.
I'm really not sure whether this is such a big issue. Can we find out which extensions are using
defaults/preferences/defaults.js
to declare their preferences?
I didn't know that feature until recently, so one of my extension does:
let defaultsBranch = Services.prefs.getDefaultBranch('extensions.Sfreq.');
defaultsBranch.setBoolPref("compareEmailOnly", true);
And that's all that's needed, albeit, for every preference.
Jörg.
Jörg Knobloch wrote on 02.11.17 20:41:
I'm really not sure whether this is such a big issue. Can we find out
which extensions are using
defaults/preferences/defaults.js
to declare their preferences?
I would hope that it's (almost) all of them.
It's simply good coding practice to make policies a preference, and to
separate out the default policies in such a file, and document them this
way. It also helps about:config. After all, preferences are something
that the user might want to change. So, burying them in code is
counter-productive.
I think we'll need to have our own branch of Gecko. We still merge
daily, like we do today, but we can apply patches on top. It's basically
a patch queue, the same approach as Debian does, which uses upstream
plus patches. Just that we use hg to maintain the patches.
Ben
On 02.11.17 20:58, Ben Bucksch wrote:
Jörg Knobloch wrote on 02.11.17 20:41:
I'm really not sure whether this is such a big issue. Can we find out
which extensions are using
defaults/preferences/defaults.js
to declare their preferences?
I would hope that it's (almost) all of them.
It's simply good coding practice to make policies a preference, and to
separate out the default policies in such a file, and document them this
way. It also helps about:config. After all, preferences are something
that the user might want to change. So, burying them in code is
counter-productive.
Indeed yes. I use(d) this in all of my extensions. And I'm sure that
many others use this feature as well.
I think we'll need to have our own branch of Gecko. We still merge
daily, like we do today, but we can apply patches on top. It's basically
a patch queue, the same approach as Debian does, which uses upstream
plus patches. Just that we use hg to maintain the patches.
I see your point, and it's certainly the easiest solution from the
add-on authors point of view - but that's basically a kind of slow fork.
-Patrick
Patrick Brunschwig wrote on 02.11.17 21:12:
I think we'll need to have our own branch of Gecko. We still merge
daily, like we do today, but we can apply patches on top. It's basically
a patch queue, the same approach as Debian does, which uses upstream
plus patches. Just that we use hg to maintain the patches.
I see your point, and it's certainly the easiest solution from the
add-on authors point of view - but that's basically a kind of slow fork.
I am strongly and fiercely against a fork, so I completely concur with
your sentiment.
A fork is essentially a copy at a given time, then you modify the copy
to your heart's content, and you don't look back. You make no serious
efforts to keep your fork in sync with upstream.
What I suggest is that we make a patchset on top of upstream, and we
keep up to date to upstream daily, as we do now. In case an upstream
change breaks the patch, the patch needs to be fixed, but that's already
the status quo with most of Thunderbird code, which already heavily
depends on Gecko.
So, I do not suggest that we change our approach. Just that we apply a
certain patchset on top of Gecko, and keep it fresh daily.
Technically, I suggest to use a hg branch and rebase it daily. This way,
the tools make it easy to see how the diff evolves over time, without
having to read a diffs of a diff.
This is how I always maintained Gecko changes in the projects I ran.
I've almost always needed some Gecko changes.
It's a tradeoff. In this case, I think it's easier to main this patch
than fix all addons.
Ben
On 02-11-2017 16:22, Ben Bucksch wrote:
Also, about:config will be broken, because users want to see the
preferences that are available (even if they didn't change them yet).
It doesn't seem that would be broken, but sure, you couldn't see if it's
the default value or not.
What an add-on would do is to install-time unconditionally write the
prefs it needs. It doesn't sound that complicated. How many prefs does
an add-on need anyway?
-Magnus