Magnus Melin wrote on 02.11.17 21:50:

It breaks the list of available and unmodified preferences, which is
important for users of about:config.

The problem is not the amount of code needed, but the fact that the
extension will break and that the extension code has to be touched.
Would you like to do that for all our extensions? Neither do I. Neither
will their authors, because they are long gone.

If we want to kill addons, we should say it outright and be done with it.

Ben

On 02-11-2017 23:19, Ben Bucksch wrote:

You're empathizing the AND here. I don't think users care that much if
it's an add-on's default value or not.

But they will have to. The days of just not upgrading the add-on code
between releases is simply gone. Gone! All add-ons that want to continue
functioning will have to be touched, that's just reality.

I have no desire to kill add-ons, but if they don't upgrade that's not a
burden we can carry.

 -Magus

Magnus Melin wrote on 02.11.17 22:35:

No, that's not my point. If there's no default pref, and the user hasn't
change the pref yet, it will not appear in the list at all.

There will no longer be a list of all prefs. The user has the know the
pref by some other means, and manually add and enter the pref name by hand.

The user wants to see what he can change, before he changed it.

It's also a reality that the vast majority of addons have no active
maintainer anymore, but work fine since years. The vast majority will
disappear.

Also, even for those addons that still have maintainers, they will tire
out at some point, if we let them make stupid changes like these.

Yes, we'd still have addons. Maybe 5.

For me, what matters is the amount of work required in Thunderbird vs.
the accumulated work required in all the extensions, combined. If it
takes 15 hours for us (7 hours for initial implementation plus 2 hours
for 4 bustage fixes in the next 2-3 years), and 30 minutes (including
finding the cause, fixing it, making a new release, waiting for review
approval etc.) for each addon, and that for 10000 addons, then the math
says that 10h for us is better than 5000 hours for the addon authors. In
fact, I'd find it ruthless to put that burden on them.

In this case, it is something we can carry. It's a only small change in
Gecko.

Ben

On 02-11-2017 23:54, Ben Bucksch wrote:

Well the add-on would set the prefs it's using to their defaults on install
time, so the prefs would therefore exist and show up in the list. This is not
only for the pref to show up but also so you wouldn't have to handle the
pref-not-set case every time you get the pref.

Re going around updating the code for add-ons, there are ownership and
licensing problems with that. And pulling more external things in as
"supported by core" is not a good way to grow or keep a developer community.

 -Magnus

On Fri, Nov 3, 2017 at 4:03 PM, Jörg Knobloch jorgk@jorgk.com wrote:

+1
;---)
Onno

On Fri, Nov 3, 2017 at 4:49 PM, Onno Ekker o.e.ekker@gmail.com wrote:

One problem I foresee is that in the not too distant future also the server
side handling of legacy add-ons will be dropped. When that happens, people
cannot search for new add-ons anymore and no updates can be installed
anymore.

Hey Günter,

just for clarification: Prefs support will stay in any case. It won't be
removed either way. The preferences system as a whole will continue to
exist.

We're discussing about where pref defaults come from. Extensions have
a directory profile/defaults/preferences/ , where they can place the
default preferences in the same format as Thunderbird default
preferences and as user preferences.

If this facility is removed, extensions that use default prefs in this
form (which I think are the majority of extensions that exist) will have
to be adapted, or they will break at runtime when they try to read a pref.

Ben

neandr wrote on 03.11.17 17:49: