Empathy List Archives

BB

Ben Bucksch

Fri, Nov 3, 2017 5:23 PM

Jörg Knobloch wrote on 03.11.17 18:06:

I'm looking into porting the relevant code to mailnews.

Is that possible? That would be nice. Thank you!

Ben

Jörg Knobloch wrote on 03.11.17 18:06: > I'm looking into porting the relevant code to mailnews. Is that possible? That would be nice. Thank you! Ben

N

neandr

Fri, Nov 3, 2017 5:31 PM

Thanks Jörg for clarification! And sorry if I was not clear.
Reminderfox (for example) has a /defaults/preferences/reminderfox.js in
the XPI package and those prefs are read-in at startup. As for that I
expect the problem with it, as you said it's with Lightning etc. also.

Good to here you're going to fix it on mailnews.

/And once more a big THANKS to all you work, fascinating!/

Günter

On 03.11.2017 18:06, Jörg Knobloch wrote:

On 03/11/2017 17:49, neandr wrote:

If I understand the situation correct, it's totally IMPORTANT to stay
with supporting add-on prefs!

Looking into my "profile"/extensions/prefs.js file I find MANY
preferences set by addons, including Lightning.

If I read this correctly, you misunderstood.

No one suggests to remove the ability to create add-on specific
preferences. The support that will create them by including a
defaults/preferences/xxx.js file in the add-on itself will be removed
from Daily from tomorrow.

Lightning uses this mechanism, so I assume C-C will be busted from the
next M-C merge.

I'm looking into porting the relevant code to mailnews.

Jörg.

Thanks Jörg for clarification! And sorry if I was not clear. Reminderfox (for example) has a /defaults/preferences/reminderfox.js in the XPI package and those prefs are read-in at startup. As for that I expect the problem with it, as you said it's with Lightning etc. also. Good to here you're going to fix it on mailnews. /And once more a big THANKS to all you work, fascinating!/ Günter On 03.11.2017 18:06, Jörg Knobloch wrote: > On 03/11/2017 17:49, neandr wrote: >> If I understand the situation correct, it's totally IMPORTANT to stay >> with supporting add-on prefs! >> >> Looking into my "profile"/extensions/prefs.js file I find MANY >> preferences set by addons, including Lightning. > > If I read this correctly, you misunderstood. > > No one suggests to remove the ability to create add-on specific > preferences. The support that will create them by including a > defaults/preferences/xxx.js file in the add-on itself will be removed > from Daily from tomorrow. > > Lightning uses this mechanism, so I assume C-C will be busted from the > next M-C merge. > > I'm looking into porting the relevant code to mailnews. > > Jörg. >

JK

Jörg Knobloch

Fri, Nov 3, 2017 7:59 PM

On 03/11/2017 18:06, Jörg Knobloch wrote:

The support that will create them by including a defaults/preferences/xxx.js file in the add-on itself will be removed from Daily from tomorrow.

Lightning uses this mechanism, so I assume C-C will be busted from the next M-C merge.

I'm looking into porting the relevant code to mailnews.

Hi all,

you've all read Kent's e-mail "RFC: Review policy for bustage fixes". There was only one comment, mine, so let's at least assume that there is no strong opposition.

Another day for PLR patches has come. With the next M-C merge TB testing will be obliterated so some measures need to be taken. I filed bug https://bugzilla.mozilla.org/show_bug.cgi?id=1414398 for this.

In hindsight "porting the relevant code to mailnews" is not as straight forward as forking the Necko piece back in September.

Comments welcome, otherwise hold your peace and accept whatever the "qualified developer" will implement.

Jörg.

P.S.: FORK FORK FORK is just a joke to attract attention ;-)

JK

Jörg Knobloch

Fri, Nov 3, 2017 10:05 PM

On 03/11/2017 20:59, Jörg Knobloch wrote:

Another day for PLR patches has come. With the next M-C merge TB testing will be obliterated so some measures need to be taken. I filed bug https://bugzilla.mozilla.org/show_bug.cgi?id=1414398 for this.

Looks like a false alarm. Lightning doesn't seem to be affected by the removal of the defaults/preferences/xxx.js mechanism. Maybe due to being a packaged add-on.

We still need a solution for "regular" add-ons.

Jörg.

TP

Tom Prince

Mon, Nov 6, 2017 6:26 PM

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.

We (by which I mean Andrei Hajdukewycz) is actively working on setting up a
replacement for that.

-- Tom

> > 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. > We (by which I mean Andrei Hajdukewycz) is actively working on setting up a replacement for that. -- Tom

JK

Jörg Knobloch

Mon, Nov 6, 2017 6:48 PM

On 06/11/2017 19:26, Tom Prince 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.

We (by which I mean Andrei Hajdukewycz) is actively working on setting up a replacement for that.

More severe is that support for non-bootstrapped add-ons will be dropped and no website will fix that.

https://bugzilla.mozilla.org/show_bug.cgi?id=1413413

PK

Philipp Kewisch

Mon, Nov 6, 2017 7:23 PM

On 11/6/17 7:48 PM, Jörg Knobloch wrote:

On 06/11/2017 19:26, Tom Prince 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.

We (by which I mean Andrei Hajdukewycz) is actively working on
setting up a replacement for that.

More severe is that support for non-bootstrapped add-ons will be
dropped and no website will fix that.

https://bugzilla.mozilla.org/show_bug.cgi?id=1413413

There is also bug 1413432 which seems to be more of a tracker and is
definitely worth following. We're going to have a hard time on the way
to 59, all we can do is ask nicely if they are willing the postpone the
really bad parts until 60, but I suspect the argument will be that they
don't want to maintain it for the whole ESR cycle.

That said, I think we're just going to have to suck it up and work with
what we get, asking nicely to postpone only in cases where we cannot
workaround on our side. By that I mean patches to c-c that replace the
feature, as in bug 1414398. Let's try to avoid forking as long as
possible. It might be worth asking on dev-addons for them to tell us a
timeline and discuss how far they are willing to be lenient with us.

Philipp

On 11/6/17 7:48 PM, Jörg Knobloch wrote: > On 06/11/2017 19:26, Tom Prince 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. >> >> >> We (by which I mean Andrei Hajdukewycz) is actively working on >> setting up a replacement for that. > > More severe is that support for non-bootstrapped add-ons will be > dropped and no website will fix that. > > https://bugzilla.mozilla.org/show_bug.cgi?id=1413413 > There is also bug 1413432 which seems to be more of a tracker and is definitely worth following. We're going to have a hard time on the way to 59, all we can do is ask nicely if they are willing the postpone the really bad parts until 60, but I suspect the argument will be that they don't want to maintain it for the whole ESR cycle. That said, I think we're just going to have to suck it up and work with what we get, asking nicely to postpone only in cases where we cannot workaround on our side. By that I mean patches to c-c that replace the feature, as in bug 1414398. Let's try to avoid forking as long as possible. It might be worth asking on dev-addons for them to tell us a timeline and discuss how far they are willing to be lenient with us. Philipp

JK

Jörg Knobloch

Mon, Nov 6, 2017 8:37 PM

On 06/11/2017 20:23, Philipp Kewisch wrote:

More severe is that support for non-bootstrapped add-ons will be
dropped and no website will fix that.

https://bugzilla.mozilla.org/show_bug.cgi?id=1413413

There is also bug 1413432 which seems to be more of a tracker and is
definitely worth following.

Oops, yes, that's the one I meant to paste.

On 06/11/2017 20:23, Philipp Kewisch wrote: >> >> More severe is that support for non-bootstrapped add-ons will be >> dropped and no website will fix that. >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1413413 >> > There is also bug 1413432 which seems to be more of a tracker and is > definitely worth following. > Oops, yes, that's the one I meant to paste.

OE

Onno Ekker

Tue, Nov 7, 2017 7:15 AM

On Mon, Nov 6, 2017 at 9:37 PM, Jörg Knobloch jorgk@jorgk.com wrote:

On 06/11/2017 20:23, Philipp Kewisch wrote:

More severe is that support for non-bootstrapped add-ons will be dropped
and no website will fix that.

https://bugzilla.mozilla.org/show_bug.cgi?id=1413413

There is also bug 1413432 which seems to be more of a tracker and is

definitely worth following.

Oops, yes, that's the one I meant to paste.

For my add-on Mail Redirect I've looked into this issue, and it is not that
hard to fix it, to keep the add-on working without the default preferences
in a file.

However, for the release of Thunderbird 59, there are more changes that
affect (like break) add-ons. Here are just a few I ran into:

Removal of STEEL
Removal of nsIScriptableDateFormat
Removal of nsILocalFile
Removal of for..each construct
Removal of with construct

Al these changes cause add-ons to break and require action from the add-on
developers. If the add-on developer has stopped supporting his/her add-on,
the add-on will stop working. Because of the current state of Mozilla,
Firefox, and Thunderbird, there are more and more add-on developers who
lose interest, because the future isn't clear:

Will Thunderbird survive?
Will Thunderbird continue to support non-bootstrapped add-ons?
Are there any Thunderbird specific API's available that facilitate
converting my legacy add-on to a bootstrapped add-on?
Is it even possible to convert my legacy add-on to a bootstrapped add-on?
Will it be worthwhile to do this conversion?

Onno

On Mon, Nov 6, 2017 at 9:37 PM, Jörg Knobloch <jorgk@jorgk.com> wrote: > On 06/11/2017 20:23, Philipp Kewisch wrote: > >> >>> More severe is that support for non-bootstrapped add-ons will be dropped >>> and no website will fix that. >>> >>> https://bugzilla.mozilla.org/show_bug.cgi?id=1413413 >>> >>> There is also bug 1413432 which seems to be more of a tracker and is >> definitely worth following. >> >> Oops, yes, that's the one I meant to paste. For my add-on Mail Redirect I've looked into this issue, and it is not that hard to fix it, to keep the add-on working without the default preferences in a file. However, for the release of Thunderbird 59, there are more changes that affect (like break) add-ons. Here are just a few I ran into: * Removal of STEEL * Removal of nsIScriptableDateFormat * Removal of nsILocalFile * Removal of for..each construct * Removal of with construct Al these changes cause add-ons to break and require action from the add-on developers. If the add-on developer has stopped supporting his/her add-on, the add-on will stop working. Because of the current state of Mozilla, Firefox, and Thunderbird, there are more and more add-on developers who lose interest, because the future isn't clear: * Will Thunderbird survive? * Will Thunderbird continue to support non-bootstrapped add-ons? * Are there any Thunderbird specific API's available that facilitate converting my legacy add-on to a bootstrapped add-on? * Is it even possible to convert my legacy add-on to a bootstrapped add-on? * Will it be worthwhile to do this conversion? Onno

JK

Jörg Knobloch

Tue, Nov 7, 2017 9:03 PM

On 07/11/2017 08:15, Onno Ekker wrote:

However, for the release of Thunderbird 59, there are more changes that
affect (like break) add-ons. Here are just a few I ran into:

Removal of STEEL
Removal of nsIScriptableDateFormat
Removal of nsILocalFile
Removal of for..each construct
Removal of with construct

There were a few more, most notably nsIFilePicker.show().

BTW, I'm not aware of a "with construct".

Note that legacy iterators "for ... in" were also removed, you need to
use "for ... of" now.

Jörg.

On 07/11/2017 08:15, Onno Ekker wrote: > However, for the release of Thunderbird 59, there are more changes that > affect (like break) add-ons. Here are just a few I ran into: > * Removal of STEEL > * Removal of nsIScriptableDateFormat > * Removal of nsILocalFile > * Removal of for..each construct > * Removal of with construct There were a few more, most notably nsIFilePicker.show(). BTW, I'm not aware of a "with construct". Note that legacy iterators "for ... in" were also removed, you need to use "for ... of" now. Jörg.

maildev@lists.thunderbird.net

Fwd: Re: Proposal to remove some preferences override support