Hi all, I've just stumbled upon https://bugzilla.mozilla.org/show_bug.cgi?id=1426763 - "[meta] Remove XUL overlays". That would have severe consequences for TB and be the end of all non-restartless add-ons. Or am I missing something? Jörg.

On 2/24/18 10:48 PM, Jörg Knobloch wrote: > Hi all, > > I've just stumbled upon > https://bugzilla.mozilla.org/show_bug.cgi?id=1426763 - "[meta] Remove > XUL overlays". > > That would have severe consequences for TB and be the end of all > non-restartless add-ons. Or am I missing something? > > Jörg. Good find, thanks for keeping an eye out! It would be a pretty hard blow, but probably not impossible to replicate. Back in the age of bootstrapped add-ons someone wrote a thing that basically replicated XUL overlay loading code. It was in the order of 100 lines. What we could probably do is provide a JS service that loads the traditional XUL overlay as an xml file, processes each of the nodes, and then uses simple DOM creation methods to add it to our main window. In the best case, add-on authors wouldn't have to do a thing. We could re-parse chrome.manifest to find the overlays to load. In the worst case add-on authors would need to call some JS method of ours to do their overlay loading. Philipp

Yes, overlays are central to XUL and used all over Thunderbird for many purposes - code separation, code sharing between Windows, separation between seasoned and thunderbird. removing overlays is going to be a massive amount of work and will mean a lot of code duplication, which leads to harder maintenance. -- Sent from my phone. Please excuse the brevity.

Yes, Philipp, that would be a great idea - and indeed feasible. plus, this is something we will need for TB:NG as well, to share front-end code. we should get started on an implementation ASAP. note that this will cause breakage and subtle anyway, because the load time will be different. we should plan sufficient time (6+ months after the first implementation) to fix these and find the more subtle bugs. Ben -- Sent from my phone. Please excuse the brevity.

On 25.02.18 07:19, Philipp Kewisch wrote: > On 2/24/18 10:48 PM, Jörg Knobloch wrote: >> Hi all, >> >> I've just stumbled upon >> https://bugzilla.mozilla.org/show_bug.cgi?id=1426763 - "[meta] Remove >> XUL overlays". >> >> That would have severe consequences for TB and be the end of all >> non-restartless add-ons. Or am I missing something? >> >> Jörg. > > Good find, thanks for keeping an eye out! It would be a pretty hard > blow, but probably not impossible to replicate. Back in the age of > bootstrapped add-ons someone wrote a thing that basically replicated XUL > overlay loading code. It was in the order of 100 lines. What we could > probably do is provide a JS service that loads the traditional XUL > overlay as an xml file, processes each of the nodes, and then uses > simple DOM creation methods to add it to our main window. As I feared this change would come one day, I have changed Enigmail 2.0 into a bootstrapped addon. In the course of this, I implemented almost exactly what you proposed. There are a few changes though (at least in my generic implementation): * the XUL files only get loaded after the "load" event -- this is often later in the processing than with current XUL. This is noticeable for example in the composer window. * there are some small changes required in the XUL files for loading JavaScript, and for adding toolbar buttons. <https://sourceforge.net/p/enigmail/source/ci/master/tree/package/overlays.jsm> -Patrick

Understand there are some ways to solve the problem without moving addons to bootstrapped implementation and addon authors would have no or only little problems with it. But please bear in mind there are addons which not only run on Thunderbird but also on Seamonkey or even Firefox(version and derivatives before Quantum). If that requires some different code handling or switching code versions please define that. Günter On 25.02.2018 07:19, Philipp Kewisch wrote: > On 2/24/18 10:48 PM, Jörg Knobloch wrote: >> Hi all, >> >> I've just stumbled upon >> https://bugzilla.mozilla.org/show_bug.cgi?id=1426763 - "[meta] Remove >> XUL overlays". >> >> That would have severe consequences for TB and be the end of all >> non-restartless add-ons. Or am I missing something? >> >> Jörg. > Good find, thanks for keeping an eye out! It would be a pretty hard > blow, but probably not impossible to replicate. Back in the age of > bootstrapped add-ons someone wrote a thing that basically replicated XUL > overlay loading code. It was in the order of 100 lines. What we could > probably do is provide a JS service that loads the traditional XUL > overlay as an xml file, processes each of the nodes, and then uses > simple DOM creation methods to add it to our main window. > > In the best case, add-on authors wouldn't have to do a thing. We could > re-parse chrome.manifest to find the overlays to load. In the worst case > add-on authors would need to call some JS method of ours to do their > overlay loading. > > Philipp > > > _______________________________________________ > Maildev mailing list > Maildev@lists.thunderbird.net > http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net

Can you explain further what kind of duplication you expect? Do you mean in add-ons or in Thunderbird? Philipp > On 25. Feb 2018, at 7:48 AM, Ben Bucksch <ben.bucksch@beonex.com> wrote: > > Yes, overlays are central to XUL and used all over Thunderbird for many purposes - code separation, code sharing between Windows, separation between seasoned and thunderbird. > > removing overlays is going to be a massive amount of work and will mean a lot of code duplication, which leads to harder maintenance. > -- > Sent from my phone. Please excuse the brevity. > _______________________________________________ > Maildev mailing list > Maildev@lists.thunderbird.net > http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net

I was wondering if this were possible the other day. If we move forward on this, I feel it would alleviate a lot of concerns about the looming Thunderbird changes regarding XUL. Please keep me informed, this is worthy of a blog post if we decide to implement abstraction layer. (is it fair to call it that?) On 2/25/18 4:26 AM, Patrick Brunschwig wrote: > On 25.02.18 07:19, Philipp Kewisch wrote: >> On 2/24/18 10:48 PM, Jörg Knobloch wrote: >>> Hi all, >>> >>> I've just stumbled upon >>> https://bugzilla.mozilla.org/show_bug.cgi?id=1426763 - "[meta] Remove >>> XUL overlays". >>> >>> That would have severe consequences for TB and be the end of all >>> non-restartless add-ons. Or am I missing something? >>> >>> Jörg. >> Good find, thanks for keeping an eye out! It would be a pretty hard >> blow, but probably not impossible to replicate. Back in the age of >> bootstrapped add-ons someone wrote a thing that basically replicated XUL >> overlay loading code. It was in the order of 100 lines. What we could >> probably do is provide a JS service that loads the traditional XUL >> overlay as an xml file, processes each of the nodes, and then uses >> simple DOM creation methods to add it to our main window. > As I feared this change would come one day, I have changed Enigmail 2.0 > into a bootstrapped addon. In the course of this, I implemented almost > exactly what you proposed. > > There are a few changes though (at least in my generic implementation): > * the XUL files only get loaded after the "load" event -- this is often > later in the processing than with current XUL. This is noticeable for > example in the composer window. > * there are some small changes required in the XUL files for loading > JavaScript, and for adding toolbar buttons. > > <https://sourceforge.net/p/enigmail/source/ci/master/tree/package/overlays.jsm> > > -Patrick > > _______________________________________________ > Maildev mailing list > Maildev@lists.thunderbird.net > http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net

I couple days ago I asked Andreas if we could determine which addons are affected so that we can actually measure the impact.  His response below Unfortunately, we don't have a good (=searchable) system for legacy add-ons anymore. I think at this point, your best shot is hacking https://github.com/cr/webextaware to download legacy extensions only and then doing a local search. Sorry that I don't have better news, but a searchable code storage has not been a priority so far (...believe me I tried) and legacy add-ons don't get any love at all these days. Andreas On 2/25/2018 10:27 AM, Ryan Sipes wrote: > I was wondering if this were possible the other day. If we move forward > on this, I feel it would alleviate a lot of concerns about the looming > Thunderbird changes regarding XUL. > > Please keep me informed, this is worthy of a blog post if we decide to > implement abstraction layer. (is it fair to call it that?) > > On 2/25/18 4:26 AM, Patrick Brunschwig wrote: >> On 25.02.18 07:19, Philipp Kewisch wrote: >>> On 2/24/18 10:48 PM, Jörg Knobloch wrote: >>>> Hi all, >>>> >>>> I've just stumbled upon >>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1426763 - "[meta] Remove >>>> XUL overlays". >>>> >>>> That would have severe consequences for TB and be the end of all >>>> non-restartless add-ons. Or am I missing something? >>>> >>>> Jörg. >>> Good find, thanks for keeping an eye out! It would be a pretty hard >>> blow, but probably not impossible to replicate. Back in the age of >>> bootstrapped add-ons someone wrote a thing that basically replicated XUL >>> overlay loading code. It was in the order of 100 lines. What we could >>> probably do is provide a JS service that loads the traditional XUL >>> overlay as an xml file, processes each of the nodes, and then uses >>> simple DOM creation methods to add it to our main window. >> As I feared this change would come one day, I have changed Enigmail 2.0 >> into a bootstrapped addon. In the course of this, I implemented almost >> exactly what you proposed. >> >> There are a few changes though (at least in my generic implementation): >> * the XUL files only get loaded after the "load" event -- this is often >> later in the processing than with current XUL. This is noticeable for >> example in the composer window. >> * there are some small changes required in the XUL files for loading >> JavaScript, and for adding toolbar buttons. >> >> <https://sourceforge.net/p/enigmail/source/ci/master/tree/package/overlays.jsm> >> >> -Patrick >> >> _______________________________________________ >> Maildev mailing list >> Maildev@lists.thunderbird.net >> http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net > _______________________________________________ > Maildev mailing list > Maildev@lists.thunderbird.net > http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net