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

**URL:** <https://discourse.mozilla.org/t/about-the-need-for-the-future-of-the-rewriting-of-the-add-on/8375>\
**Category:** Add-on Support\
**Created:** [April 28, 2016, 12:52pm UTC](https://discourse.mozilla.org/t/about-the-need-for-the-future-of-the-rewriting-of-the-add-on/8375 "2016-04-28T12:52:27Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![DG.WB3g](https://avatars.discourse-cdn.com/v4/letter/d/cc9497/32.png) [@DG.WB3g](https://discourse.mozilla.org/u/DG.WB3g)\
**Post date:** [April 28, 2016, 12:52pm UTC](https://discourse.mozilla.org/t/about-the-need-for-the-future-of-the-rewriting-of-the-add-on/8375/1 "2016-04-28T12:52:28Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![desktopd](https://sea1.discourse-cdn.com/flex001/user_avatar/discourse.mozilla.org/desktopd/32/4520_2.png) [@desktopd](https://discourse.mozilla.org/u/desktopd)\
**Post date:** [April 28, 2016, 2:13pm UTC](https://discourse.mozilla.org/t/about-the-need-for-the-future-of-the-rewriting-of-the-add-on/8375/2 "2016-04-28T14:13:21Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![DG.WB3g](https://avatars.discourse-cdn.com/v4/letter/d/cc9497/32.png) [@DG.WB3g](https://discourse.mozilla.org/u/DG.WB3g)\
**Post date:** [May 20, 2016, 9:31pm UTC](https://discourse.mozilla.org/t/about-the-need-for-the-future-of-the-rewriting-of-the-add-on/8375/3 "2016-05-20T21:31:33Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![desktopd](https://sea1.discourse-cdn.com/flex001/user_avatar/discourse.mozilla.org/desktopd/32/4520_2.png) [@desktopd](https://discourse.mozilla.org/u/desktopd)\
**Post date:** [May 22, 2016, 2:14pm UTC](https://discourse.mozilla.org/t/about-the-need-for-the-future-of-the-rewriting-of-the-add-on/8375/4 "2016-05-22T14:14:51Z")

</div>

**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

---

<div class="post-metadata">

**Author:** ![quicksaver](https://sea1.discourse-cdn.com/flex001/user_avatar/discourse.mozilla.org/quicksaver/32/21077_2.png) [@quicksaver](https://discourse.mozilla.org/u/quicksaver)\
**Post date:** [May 22, 2016, 2:53pm UTC](https://discourse.mozilla.org/t/about-the-need-for-the-future-of-the-rewriting-of-the-add-on/8375/5 "2016-05-22T14:53:41Z")

</div>

> [@desktopd](#):
>
> Not everything can be made restartless

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?

---

<div class="post-metadata">

**Author:** ![desktopd](https://sea1.discourse-cdn.com/flex001/user_avatar/discourse.mozilla.org/desktopd/32/4520_2.png) [@desktopd](https://discourse.mozilla.org/u/desktopd)\
**Post date:** [May 23, 2016, 2:40pm UTC](https://discourse.mozilla.org/t/about-the-need-for-the-future-of-the-rewriting-of-the-add-on/8375/6 "2016-05-23T14:40:42Z")

</div>

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.