maildev@lists.thunderbird.net

Thunderbird email developers

View all threads

Fwd: Intent to unship: bootstrapped extensions

PK
Philipp Kewisch
Tue, Jun 5, 2018 6:02 AM

Begin forwarded message:

From: Andrew Swan aswan@mozilla.com
Date: 5. June 2018 at 5:34:52 AM CEST
To: firefox-dev firefox-dev@mozilla.org, dev-addons dev-addons@mozilla.org
Subject: Intent to unship: bootstrapped extensions

Since various types of legacy extensions became unsupported in Firefox Quantum, we've been busy removing obsolete code and streamlining the Addons Manager which, as you might imagine, had become quite large and complex in order to support a wide variety of legacy addon formats.

At this point, the largest remaining category of legacy extensions is bootstrapped extensions.  We no longer support bootstrapped extensions for general use, but we do use them for things like system addons, Test Pilot experiments, Shield studies, extensions used in automation, and a few other things.  Bootstrapped extensions are useful for these applications since they provide a relatively simple way to run some chrome-privileged javascript code without having to land that code and wait for it to ride the trains.  But continuing to support these extensions comes at some cost (for instance, they are one of the last users of RDF in mozilla-central).

An important feature of WebExtensions is that they run in a sandboxed environment much like web content without direct access to chrome-privileged browser internals.  However, a feature called WebExtensions Experiments allows certain  extensions to run some privileged code.  Converting bootstrapped extensions to WebExtensions plus experiments has a bunch of advantages:

  • It means less privileged code overall which is good for stability and security
  • Though porting takes some work, the result should be easier to maintain and build on in the future
  • It frees us up to remove more old code and further streamline the addons manager

So, we plan to remove support for bootstrapped extensions altogether in Firefox 65.  This will entail porting existing bootstrapped extensions to WebExtensions (or converting them to something other than an extension where that is appropriate).  This effort is tracked in bug 1449052.  If you are responsible for a bootstrapped extension that we rely on and it is not already tracked as a dependency of that bug,  please:

  1. Add a comment or dependency. to bug 1449052, and
  2. Aim to get the extension converted by the end of the 64 Nightly cycle (Oct 15)

And needless to say, we shouldn't be creating any new bootstrapped extensions at this point.

A lot of things are going to need to come together to hit his schedule but we are eager to get this wrapped up and move on.  If you are responsible for an extension and have questions about how to handle it, feel free to either contact me directly or drop into #webextensions on IRC.  If you want to learn more about WebExtensions Experiments, there is a brief overview at [1] and a lot of gory implementation details at [2].

[1] https://webextensions-experiments.readthedocs.io/en/latest/
[2] https://firefox-source-docs.mozilla.org/toolkit/components/extensions/webextensions/index.html


firefox-dev mailing list
firefox-dev@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev

Begin forwarded message: > From: Andrew Swan <aswan@mozilla.com> > Date: 5. June 2018 at 5:34:52 AM CEST > To: firefox-dev <firefox-dev@mozilla.org>, dev-addons <dev-addons@mozilla.org> > Subject: Intent to unship: bootstrapped extensions > > > Since various types of legacy extensions became unsupported in Firefox Quantum, we've been busy removing obsolete code and streamlining the Addons Manager which, as you might imagine, had become quite large and complex in order to support a wide variety of legacy addon formats. > > At this point, the largest remaining category of legacy extensions is bootstrapped extensions. We no longer support bootstrapped extensions for general use, but we do use them for things like system addons, Test Pilot experiments, Shield studies, extensions used in automation, and a few other things. Bootstrapped extensions are useful for these applications since they provide a relatively simple way to run some chrome-privileged javascript code without having to land that code and wait for it to ride the trains. But continuing to support these extensions comes at some cost (for instance, they are one of the last users of RDF in mozilla-central). > > An important feature of WebExtensions is that they run in a sandboxed environment much like web content without direct access to chrome-privileged browser internals. However, a feature called WebExtensions Experiments allows certain extensions to run some privileged code. Converting bootstrapped extensions to WebExtensions plus experiments has a bunch of advantages: > - It means less privileged code overall which is good for stability and security > - Though porting takes some work, the result should be easier to maintain and build on in the future > - It frees us up to remove more old code and further streamline the addons manager > > So, we plan to remove support for bootstrapped extensions altogether in Firefox 65. This will entail porting existing bootstrapped extensions to WebExtensions (or converting them to something other than an extension where that is appropriate). This effort is tracked in bug 1449052. If you are responsible for a bootstrapped extension that we rely on and it is not already tracked as a dependency of that bug, please: > 1. Add a comment or dependency. to bug 1449052, and > 2. Aim to get the extension converted by the end of the 64 Nightly cycle (Oct 15) > > And needless to say, we shouldn't be creating any new bootstrapped extensions at this point. > > A lot of things are going to need to come together to hit his schedule but we are eager to get this wrapped up and move on. If you are responsible for an extension and have questions about how to handle it, feel free to either contact me directly or drop into #webextensions on IRC. If you want to learn more about WebExtensions Experiments, there is a brief overview at [1] and a lot of gory implementation details at [2]. > > [1] https://webextensions-experiments.readthedocs.io/en/latest/ > [2] https://firefox-source-docs.mozilla.org/toolkit/components/extensions/webextensions/index.html > > > _______________________________________________ > firefox-dev mailing list > firefox-dev@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev
JK
Jörg Knobloch
Tue, Jun 5, 2018 10:49 AM

On 05/06/2018 08:02, Philipp Kewisch wrote:

Begin forwarded message:

From: Andrew Swan <aswan@mozilla.com>
Date: 5. June 2018 at 5:34:52 AM CEST
To: firefox-dev <firefox-dev@mozilla.org>, dev-addons <dev-addons@mozilla.org>
Subject: Intent to unship: bootstrapped extensions

Note my reply to the list, currently stuck in moderation, hence included below.

Thunderbird testing relies on the MozMill and JSBridge extensions.

Jörg.


On 05/06/2018 05:34, Andrew Swan wrote:

So, we plan to remove support for bootstrapped extensions altogether in Firefox 65. This will entail porting existing bootstrapped extensions to WebExtensions (or converting them to something other than an extension where that is appropriate).

This is somewhat different to the comment by Kris in https://bugzilla.mozilla.org/show_bug.cgi?id=1413432#c7:

===

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.

===

Could you please clarify this.

Jörg.