About the need for the future of the rewriting of the add-on

Add-ons Add-on Support
#1

Some addons that I have may need to rewrite in the future. so I want to confirm two issues:

  1. Whether the current ID I’m using is able to take over.
  2. When the addons created by the JPM (the low level API such as
    window/utils、ui/button/action、sdk/tabs/utils) will become unusable?
#2

If your add-ons are e10s-ready they will, I suppose, survive for some long period, until the anticipated final deprecation day for all the traditional add-ons.

#3

I need more information. Can you tell me in detail?
I want to know must have a corresponding to indefinitely.

#4

Future Firefox add-ons development

Options:

  1. WebExtensions
  • The Mozilla-recommended way of creating add-ons
  • When you do not have to support older Firefox versions (e.g. ESR or non-Mozilla builds)
  • When you do not have to support anything other than Firefox (e.g. Thunderbird, Seamonkey, or forks) It may and should change in the future
  • No real UI is available for Android (Fennec) right now
  • When all the APIs you need are already available
  • When you happens to port a G. Chrome extension to Firefox
  • You do not have to support G. Chrome to use the WebExtensions APIs
  1. High-level APIs from the Add-on SDK
  • When you have to support older (but not too old) Firefox releases
  • When the add-on is nothing more than a button and a content script
  • No serious support for Android, Thunderbird, etc.
  • No clear plans for deprecation
  1. Low-level APIs from the Add-on SDK, or bootstrapped (restartless) non-SDK add-ons
  • You need to support e10s (multiprocess Firefox)
    • No direct content access from the main process
    • Frame scripts, Inter-process messaging, etc.
    • Not affected when you do not use low-level APIs for content access
  • Not everything can be made restartless, but if you are not sure you are probably unaffected
  • You can use js-ctypes, JSMs, and XPCOM!
  1. Traditional overlay add-ons
  • Who knows?
  • The zen of the traditional add-ons development for more than a decade
  • Multiprocess support mandatory (see above)
  • Guaranteed to remain available through 2017
  • Probably you should not be using native components
  1. (Future) Native.js with WebExtensions
  • Use XPCOM and JSM from WebExtensions indirectly
  • Guaranteed to break (you need to update your use of Native.js all the time)
  • No concrete plans published

Multiprocess Firefox does not necessitates WebExtnsions by itself. You need to make sure all your add-ons support it first. Tranditional add-ons are not really deprecated yet.

Things that can break traditional add-ons:

  • Mozilla may replace C++ XPCOM with typesafe Rust code for example
  • XUL can be faded out as HTML becomes richer.

We all hope Firefox evolve in a way that makes advanced customization always possible. Firefox is now effectively the only modern graphical Web browser that can be used in various unexpected interesting ways. We do not want to lose that ability. But it does not mean that old add-ons will not require updates.

Disclaimer: Not a comment by a Mozilla employee

#5

I don’t agree, so far everything I’ve ever seen in an(y) add-on can/could be made restartless; some things would require more work than others of course. Do you have any specific examples of what can’t be made restartless?

#6

Sometimes alternatives are not feasible or well known for:

  • Binary components (actually needed by very few things, though porting is not necessarily easy even in “possible” cases)
  • Overriding some locale strings in the browser UI (I’ve heard this problem once, where DOM changes and bootstrapped locale registrations are not reliably reflected)
  • This includes things technically possible in bootstrapped extensions that do not work as intended in practice.

Possibly in some of the failed cases there might be workarounds that is not well known. Reading a lot of mozilla-central source code might also help.

In short: These are exceptions. Anything typical of an “add-on” can be made restartless. Correct me if I’m wrong.