The end of non-restartless add-ons - The future of Lightning - Loss of Mozmill - Tree closure
Yes, of course. There are definitely some APIs that would qualify for a
basic set that we should be working on, and if we can also engage
developers of add-ons that use it to support us that would allow for
great synergy. Thanks for the reminder on STEEL, I agree it is a good
starting point.
Philipp
On 4/4/18 12:11 PM, Ben Bucksch wrote:
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:
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
On 30. Mar 2018, at 11:23 AM, Patrick Brunschwig patrick@enigmail.net wrote:
On 29.03.18 23:39, Jörg Knobloch wrote:
On 27/03/2018 18:02, Jörg Knobloch wrote:
today M-C landed a change to finally disable the installation of
non-restartless add-ons.
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.
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
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
On Wed Apr 04 2018 06:11:00 GMT-0400 (Eastern Standard Time), Ben
Bucksch ben.bucksch@beonex.com wrote:
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).
When you say 'add a good base set of APIs', do you mean create
new/additional WebExtension APIs just for Thunderbird?
Or are you taking about something else?
Unless I'm misunderstanding something, I think Philipp Kewisch's suggestion:
"For the missing functionality, they would write experiment apis that
can use xpcom, using a set of guidelines we prepare."
is not the way to go. What should be done is to create additional pure
WebExtension APIs that allow access to whatever is needed.
As I have said in the past, this is the only thing that makes sense. It
allows us to move forward even beyond whe XUL/XPCOM are ripped out and
no longer options.
Also, I also think that we could/should collaborate with the Firefox
forks, so they could take advantage of these APIs as well (and help
create, test and maintain them). These additional WebExtension APIs
could then be proposed to be added to the core Mozilla WebExtension APIs.
On 4/4/18 2:57 PM, Tanstaafl wrote:
On Wed Apr 04 2018 06:11:00 GMT-0400 (Eastern Standard Time), Ben
Bucksch ben.bucksch@beonex.com wrote:
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).
When you say 'add a good base set of APIs', do you mean create
new/additional WebExtension APIs just for Thunderbird?
Yes, new/additional WebExtension APIs for Thunderbird. For example, one
to add a listener when a mail is received, or sent.
Or are you taking about something else?
Unless I'm misunderstanding something, I think Philipp Kewisch's suggestion:
"For the missing functionality, they would write experiment apis that
can use xpcom, using a set of guidelines we prepare."
is not the way to go. What should be done is to create additional pure
WebExtension APIs that allow access to whatever is needed.
This is just a misunderstanding, sorry for being unclear. On the
outside, they would be pure WebExtension APIs. Extension Authors would
not use any XUL/XPCOM, they would just use the WebExtension API, which
is defined by the "WebExtension Experiment", or when it graduates from
an experiement then similar code in Thunderbird. This is basically the
definition for the WebExtension API.
The only thing that can use xpcom (and must actually), is the definition
layer, so the WebExtension Experiment. It needs some way to communicate
with our core code, which is built using XPCOM. For example, the
FileLink API: On the outside (WebExtension API), there would just be
something like browser.cloudfile.onUploadFile.addListener((fileInfo,
abortSignal) => { ... }); while on the inside (WebExtension Experiment)
it would implement the current classes required to create a FileLink
provider.
Once this is set, we have a defined WebExtension API on the outside that
add-on authors can use, based on our current code. Then we don't have to
worry about compatibility, and can replace the current code with
whatever we please, for example a pure JS class.
This is essentially what Firefox is doing as well: Lets take the tabs
API: On the outside, there is a defined WebExtension API that will allow
you to open/close and interact with tabs, on the inside it uses all the
nitty-gritty xpcom stuff required to interact with tabs:
nsIObserverService, JSMs, access to window.gBrowser, the message
manager, etc.
Also, I also think that we could/should collaborate with the Firefox
forks, so they could take advantage of these APIs as well (and help
create, test and maintain them). These additional WebExtension APIs
could then be proposed to be added to the core Mozilla WebExtension APIs.
If there is an API that makes sense for Firefox which is created for
Thunderbird, this is exactly the way to go: create a WebExtension
Experiment, and have them consider it for addition in Firefox. The only
difference is that Firefox does not have Experiments enabled in release,
because there they are really just experiments.
Philipp
On Thu Apr 05 2018 04:52:39 GMT-0400 (Eastern Standard Time), Philipp
Kewisch kewisch@thunderbird.net wrote:
Yes, new/additional WebExtension APIs for Thunderbird. For example, one
to add a listener when a mail is received, or sent.
Whew... ;)
This is just a misunderstanding, sorry for being unclear. On the
outside, they would be pure WebExtension APIs. Extension Authors
would not use any XUL/XPCOM, they would just use the WebExtension
API, which is defined by the "WebExtension Experiment", or when it
graduates from an experiement then similar code in Thunderbird. This
is basically the definition for the WebExtension API.
Ok, but...
The only thing that can use xpcom (and must actually), is the
definition layer, so the WebExtension Experiment. It needs some way
to communicate with our core code, which is built using XPCOM.
So... and forgive me if I'm still missing something, but if I am, then I
imagine others are too...
What does creating these additional WebExtension APIs really gain us, if
they still rely on the existence of core code (XUL/XPCOM) that is going
away very soon (before the next Thunderbird RELEASE version (67 or
whatever)? anything, except that the Addons won't have to be rewritten
if/when the core code is rewritten ti remove XUL/XPCOM?
For example, the FileLink API: On the outside (WebExtension API),
there would just be something like
browser.cloudfile.onUploadFile.addListener((fileInfo, abortSignal)
=> { ... }); while on the inside (WebExtension Experiment) it would
implement the current classes required to create a FileLink
provider.
And the big question - will these 'WebExtension Experiments' will be
able to continue to function after Mozilla totally rips XUL/XPCOM out?
Sorry, I guess maybe I shouldn't even engage in this discussion since I
don't understand the fundamental issues well enough...
If there is an API that makes sense for Firefox which is created for
Thunderbird, this is exactly the way to go: create a WebExtension
Experiment, and have them consider it for addition in Firefox. The
only difference is that Firefox does not have Experiments enabled in
release, because there they are really just experiments.
But my main point was I think we should take this opportunity to
establish a centralized system outside of Mozilla's control that creates
and maintains additional WebExtensions APIs that can serve both
Thunderbird and the Firefox forks - ie, PaleMoon, WaterFox, CyberFox,
etc - that want to continue to provide the ability to make
customizations beyond what Mozilla wants to provide. This would mean
we'd have help maintaining the system/site itself, and it would also
serve to facilitate getting hese new APIs into the Mozilla core code -
ie, the work is DONE, they would only need to approve adding it, and
maybe we could even provide the devs to do that as well.
Anyway, thats what I would do if I was King for a day...
We want the same thing, I assure you. What I mean is that in WebExtension Experiments we have access to XPCOM. I’m not saying we should be creating new xpcom components, but a part of the codebase currently uses xpcom and we want to be able to call into that. If we would want to implement these apis completely without touching xul/xpcom, then the first api we implement would block on removing all xpcom from Thunderbird and replacing the Mozilla Platform with something else.
The WebExtension Experiments will continue to work without xpcom, over time we would be removing calls into xpcom as the underlying interfaces are replaced
Philipp
On 5. Apr 2018, at 2:58 PM, Tanstaafl tanstaafl@libertytrek.org wrote:
On Thu Apr 05 2018 04:52:39 GMT-0400 (Eastern Standard Time), Philipp
Kewisch kewisch@thunderbird.net wrote:
Yes, new/additional WebExtension APIs for Thunderbird. For example, one
to add a listener when a mail is received, or sent.
Whew... ;)
This is just a misunderstanding, sorry for being unclear. On the
outside, they would be pure WebExtension APIs. Extension Authors
would not use any XUL/XPCOM, they would just use the WebExtension
API, which is defined by the "WebExtension Experiment", or when it
graduates from an experiement then similar code in Thunderbird. This
is basically the definition for the WebExtension API.
Ok, but...
The only thing that can use xpcom (and must actually), is the
definition layer, so the WebExtension Experiment. It needs some way
to communicate with our core code, which is built using XPCOM.
So... and forgive me if I'm still missing something, but if I am, then I
imagine others are too...
What does creating these additional WebExtension APIs really gain us, if
they still rely on the existence of core code (XUL/XPCOM) that is going
away very soon (before the next Thunderbird RELEASE version (67 or
whatever)? anything, except that the Addons won't have to be rewritten
if/when the core code is rewritten ti remove XUL/XPCOM?
For example, the FileLink API: On the outside (WebExtension API),
there would just be something like
browser.cloudfile.onUploadFile.addListener((fileInfo, abortSignal)
=> { ... }); while on the inside (WebExtension Experiment) it would
implement the current classes required to create a FileLink
provider.
And the big question - will these 'WebExtension Experiments' will be
able to continue to function after Mozilla totally rips XUL/XPCOM out?
Sorry, I guess maybe I shouldn't even engage in this discussion since I
don't understand the fundamental issues well enough...
If there is an API that makes sense for Firefox which is created for
Thunderbird, this is exactly the way to go: create a WebExtension
Experiment, and have them consider it for addition in Firefox. The
only difference is that Firefox does not have Experiments enabled in
release, because there they are really just experiments.
But my main point was I think we should take this opportunity to
establish a centralized system outside of Mozilla's control that creates
and maintains additional WebExtensions APIs that can serve both
Thunderbird and the Firefox forks - ie, PaleMoon, WaterFox, CyberFox,
etc - that want to continue to provide the ability to make
customizations beyond what Mozilla wants to provide. This would mean
we'd have help maintaining the system/site itself, and it would also
serve to facilitate getting hese new APIs into the Mozilla core code -
ie, the work is DONE, they would only need to approve adding it, and
maybe we could even provide the devs to do that as well.
Anyway, thats what I would do if I was King for a day...
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
Why are you not using Reply-List? When you Reply All I don't get the
list copy, breaking Reply-List for me.
On Sat Apr 07 2018 11:00:50 GMT-0400 (Eastern Standard Time), Philipp
Kewisch kewisch@thunderbird.net wrote:
We want the same thing, I assure you.
I believe you, I'm just having trouble either understanding the
responses or making myself clear - or both. Apologies...
What I mean is that in WebExtension Experiments we have access to
XPCOM. I’m not saying we should be creating new xpcom components, but
a part of the codebase currently uses xpcom and we want to be able to
call into that.
Ok, and again, those would stop working as soon as XPCOM (or the XPCOM
component called) was removed by Mozilla, rendering it dead.
If we would want to implement these apis completely without
touching xul/xpcom, then the first api we implement would block on
removing all xpcom from Thunderbird and replacing the Mozilla
Platform with something else.
Ok, there is a disconnect somewhere.
Again, I'm talking about maintaining these new APIs OUTSIDE of Mozilla's
control/servers... at least I thought that is what you (I think it was
you) were talking about a while back.
I still fail to understand why this approach hasn't been excitedly
engaged in by WaterFox, Basilisk/Pale Moon and the other Firefox forks
that want more APIs (capabilities to modify the UI/functionality) than
Mozilla is providing.
The WebExtension Experiments will continue to work without xpcom,
over time we would be removing calls into xpcom as the underlying
interfaces are replaced
Which sounds reasonable and what I was thinking/hoping for.
Anyway,
On 7. Apr 2018, at 6:10 PM, Tanstaafl tanstaafl@libertytrek.org wrote:
Why are you not using Reply-List? When you Reply All I don't get the
list copy, breaking Reply-List for me.
Sorry, I’m not always replying from Desktop and my mobile client does not have reply list. Maybe a bug to fix in Thunderbird? :)
On Sat Apr 07 2018 11:00:50 GMT-0400 (Eastern Standard Time), Philipp
Kewisch kewisch@thunderbird.net wrote:
We want the same thing, I assure you.
I believe you, I'm just having trouble either understanding the
responses or making myself clear - or both. Apologies...
What I mean is that in WebExtension Experiments we have access to
XPCOM. I’m not saying we should be creating new xpcom components, but
a part of the codebase currently uses xpcom and we want to be able to
call into that.
Ok, and again, those would stop working as soon as XPCOM (or the XPCOM
component called) was removed by Mozilla, rendering it dead.
Yes, that is true. We can certainly avoid calling uncommon m-c xpcom components, but some are unavoidable as long as we are using the Mozilla platform. For example, nsIIOService contains a lot of very fundamental methods. Luckily this will probably also be one of the last xpcom components to go.
If we would want to implement these apis completely without
touching xul/xpcom, then the first api we implement would block on
removing all xpcom from Thunderbird and replacing the Mozilla
Platform with something else.
Ok, there is a disconnect somewhere.
Again, I'm talking about maintaining these new APIs OUTSIDE of Mozilla's
control/servers... at least I thought that is what you (I think it was
you) were talking about a while back.
I’m not sure what you mean with outside of Mozillas control. Unless we want to reimplement the whole WebExtensions architecture ourselves, which a team of engineers have been working on for quite a while, we are going to have a certain amount of dependencies. Luckily the interfaces are very clean and don’t require vast use of internal methods.
I still fail to understand why this approach hasn't been excitedly
engaged in by WaterFox, Basilisk/Pale Moon and the other Firefox forks
that want more APIs (capabilities to modify the UI/functionality) than
Mozilla is providing.
They are mostly trying to keep legacy addons alive, so they can already do everything. I think at least one of the forks embraces WebExtensions, and if they are using a recent version of m-c they they will also do the integration the same way we would, with experiments that become core apis.
The WebExtension Experiments will continue to work without xpcom,
over time we would be removing calls into xpcom as the underlying
interfaces are replaced
Which sounds reasonable and what I was thinking/hoping for.
Anyway,