On 27.03.18 18:02, Jörg Knobloch wrote:

Well yes I do ;-) Bootstrapped addons (unlike WebExtensions) can merge
anything they want into the DOM tree. So what I do with Enigmail is to
load the XUL "overlays" into an XML document, and apply the elements one
by one to the DOM tree. I'm currently reworking that module into a
general-purpose library that can be used by any bootstrapped add-on.

I have to emphasize here, that this was quite a big effort for me. I
spent many days converting Enigmail to a bootstrapped addon. I would
assume that Lightning is similar.

Is it possible to temporarily "undo" that patch in comm-central?

-Patrick

On 27/03/2018 18:31, Patrick Brunschwig wrote:

You mean the DOM tree that represents the user interface. So you go in
and, say, after some widget, you insert another. Hmm.

Well, we have about a year, which is the life-span of TB 60 ESR. "Weeks"
doesn't sound so bad. My preference would be to integrate Lightning into
TB which should just be a packaging exercise.

comm-central is built with mozilla-central and comm-beta is built with
mozilla-beta. The change is not in mozilla-beta so TB 60 beta and the
future ESR are not affected.

It is not possible to undo a m-c change in c-c. All you can do it a try
run with the whatever modification to the underlying m-c code that you
like. But it's very cumbersome to do and will be more cumbersome as time
progresses. Today it might be possible to do a try with one m-c patch
backed out, but as more layers are placed onto of that m-c patch,
backing it out will become harder and eventually impossible.

Jörg.

On 27-03-2018 20:05, Jörg Knobloch wrote:

Yes playing with patches will become difficult.

The single repository sure would have come in handy right about now.
(See the "single repository for thunderbird" thread).

 -Magnus

Some more details would be helpful!
Maybe you can help with some links so everybody can read more about it.

I fully respect everybody is under pressure with the situation, but I
expect more details especially from members of the council! (.. or the
old council, tomorrow we will see how the resonance is about).
Guenter

On 27.03.18 20:43, Magnus Melin wrote:

I was referring to
http://lists.thunderbird.net/pipermail/maildev_lists.thunderbird.net/2017-November/000875.html

If we had the single repository it would be trivial to temporarily
exclude some m-c landings while we work out a solution.
It then depends on the actual change if it's feasible to keep it
excluded long-term, since dependent features might also change to make
it a no-op. (Then you may exclude that changeset too, but after a few
such steps things quickly get out of hand.)

 -Magnus

On 27-03-2018 21:56, neandr wrote:

On 27/03/2018 18:02, Jörg Knobloch wrote:

Update:

Mozmill testing has been restored. The tree is open again, however,
please use the "checkin needed" service.

Mozmill testing for Lightning was disabled. Lightning is still built but
will most likely not function.

For the future of add-ons, please read below.

Jörg.

https://bugzilla.mozilla.org/show_bug.cgi?id=1413432#c7 - Quote:

Q: Does it make sense to make some Thunderbird add-ons bootstrapped?

A: That's a complicated question. The answer is somewhere between yes
and no.

Bootstrapped extensions in their current form are going away, at least
in Firefox. For a start, we're working on removing support for RDF,
which means install.rdf support will have to go. I'm also planning to
remove support for loading extension chrome.manifest files, for
performance reasons, once system add-ons have finished migrating to Fluent.

That said, we're going to continue supporting some form of bootstrapped
add-ons that are as powerful as current bootstrapped add-ons. For
Firefox, that will probably mean WebExtensions with embedded experiment
APIs.

For Thunderbird, I'm willing to provide hooks so that you can handle
loading bootstrapped add-ons however you want, just so long as the code
for dealing with bootstrap scopes and chrome manifest files lives in
comm-central.

On 29.03.18 23:39, Jörg Knobloch wrote:

I consider this pretty good news. It will allow us to continue to
somehow implement powerful add-ons that require access to XPCOM and XUL.

We may need to put some effort into it, but I'm willing to help out once
these changes are coming.

-Patrick

This is along the lines of what I have been thinking as well. My idea was to allow WebExtension Experiments on release in Thunderbird, and encourage add-on authors to adapt their add-ons to mainly be a WebExtension. For the missing functionality, they would write experiment apis that can use xpcom, using a set of guidelines we prepare.

The experiment apis should be submitted as a PR to a webextension-experiments repo on our github account, which we can then give feedback on, and accept those that follow our guidelines and have potential. We can take the good ones and integrate them into Thunderbird

We need to be careful to not allow EVERYTHING as an api, otherwise we’ll never be able to do any refactoring without breaking add-ons, and of course there is the expectancy that any api we accept will be maintained going forward, which requires developer time. It also means we will need to limit the UI exposed to add-ons, otherwise we spend a lot of effort maintaining apis that target UI we might want to change or remove.

The docs on wx experiments are a bit out of date, I’m looking to create a sample api for FileLink soon that will demonstrate how it works.

Philipp

I think the TB project should add a good base set of APIs.

A good starting point for APIs might be STEEL
https://wiki.mozilla.org/User:Jminta/Steel (not the implementation,
but the API signatures, more or less).

Philipp Kewisch wrote on 30.03.18 19:34: