|
|
| Line 14: |
Line 14: |
|
| |
|
| =Developers who are affected by the changes= | | =Developers who are affected by the changes= |
| '''~~NEW~~''' there is now a [https://compatibility-lookup.services.mozilla.com/ lookup tool] you can use to see if your add-on will be affected by the changes.
| |
|
| |
|
| ==1) Has SDK add-on using low level APIs==
| | Please see the MDN article on [https://developer.mozilla.org/en-US/Add-ons/Working_with_multiprocess_Firefox "Working with multiprocess Firefox"] for suggestions on adapting to multiple processes. |
| Developers who created an SDK add-on using [https://developer.mozilla.org/Add-ons/SDK/Low-Level_APIs low-level APIs], which break with Multi-process Firefox (aka Electrolysis or e10s).
| |
| =====Migration Path=====
| |
| If your add-on code accesses web content using a [https://developer.mozilla.org/Add-ons/SDK/Low-Level_APIs low-level SDK APIs] like window/utils or tabs/utils, then you will likely be affected.<br />
| |
| '''''Multi-process Firefox is scheduled for release in the [[Electrolysis#Schedule next|few months]], so we urge you to [https://developer.mozilla.org/Add-ons/SDK/Guides/Multiprocess_Firefox_and_the_SDK test your add-ons] for compatibility.'''''<br />
| |
| | |
| *'''If it breaks''' in Multi-process Firefox, your users will be impacted, and you will need to update your add-on. You can find documentation on how to make them compatible [https://developer.mozilla.org/en-US/Add-ons/Working_with_multiprocess_Firefox here].<br />
| |
| *'''If it does not break''' in Multi-process Firefox, you will should add the [https://developer.mozilla.org/Add-ons/SDK/Tools/package_json#Key_reference <code>multiprocess</code> permission] in package.json.
| |
| | |
| There are people on hand to assist you [http://atsay.github.io/e10s_office_hours/ '''every Tuesday'''] in the #addons channel at [https://wiki.mozilla.org/IRC irc.mozilla.org]. We're here to help!
| |
| | |
| '''~~Attention SDK developers~~'''<br />
| |
| As of March 2016, SDK add-ons that were built using the cfx tool (Jetpack version 1.17 and lower) need to be repackaged using the [https://developer.mozilla.org/en-US/Add-ons/SDK/Tools/cfx_to_jpm newer jpm tool] in order to continue being compatible with Firefox. jpm will be supported for as long as the SDK is.
| |
| | |
| ==2) Has SDK add-on using legacy APIs==
| |
| Developers who created an SDK add-on, but uses either XPCOM or other legacy APIs.
| |
| | |
| =====Migration Path=====
| |
| Developers in this group potentially have to update their add-on twice--once for e10s compatibility (if using [https://developer.mozilla.org/Add-ons/SDK/Low-Level_APIs low-level APIs]), and again for WebExtensions compatibility (because it uses legacy APIs).
| |
| | |
| #'''Use only [https://developer.mozilla.org/Add-ons/SDK/High-Level_APIs high-level APIs]''' - High-level APIs are [https://wiki.mozilla.org/Add-ons/developer/communication#1.29_Has_SDK_add-on_using_low_level_APIs e10s compatible] and are more likely to have an equivalent WebExtensions API. You will have to migrate again once WebExtensions are fully ready, but it should be pretty easy to do in this case.
| |
| #'''Move to [[WebExtensions|WebExtensions]]''' - WebExtensions may not have all the APIs you need yet, so you might have to limit the functionality of your add-on until they become available. Please use [http://bit.ly/webextensions-apis this survey] to tell us which APIs you need, and see what else we're doing to [[Add-ons/developer/communication#Managing_the_Impact|mitigate the impact]] of this transition.
| |
| | |
| ==3) Has SDK add-on using only high level APIs==
| |
| Developers who used the SDK for their add-ons using only [https://developer.mozilla.org/Add-ons/SDK/High-Level_APIs high-level APIs]. Might have played around with the Chrome extension API in the past.
| |
| =====Migration Path=====
| |
| *As of March 2016, SDK add-ons that were built using the cfx tool (Jetpack version 1.17 and lower) need to be repackaged using the [https://developer.mozilla.org/Add-ons/SDK/Tools/cfx_to_jpm newer jpm tool] in order to continue being compatible with Firefox.
| |
| *If you already do that, your add-on will probably continue to work without problems, but we recommend you start looking into [https://developer.mozilla.org/Add-ons/WebExtensions WebExtensions].
| |
| *Please use [http://bit.ly/webextensions-apis this survey] to tell us which APIs you need in WebExtensions. This will help us prioritize and plan for what we need to support.
| |
| | |
| ==4) Has XUL or XPCOM add-on==
| |
| Developers who created add-ons that don't rely on the SDK or WebExtensions.
| |
| =====Migration Path=====
| |
| The transition to WebExtensions impacts add-ons built on APIs like XUL and XPCOM most of all. We expect to remove support for these technologies in Firefox add-ons by the end of 2017. We hope this will give us enough time to help you migrate and provide WebExtension APIs that are suitable for replacing the features you might lose once we stop supporting these APIs.
| |
| | |
| If you’ve already updated your add-on for Multiprocess Firefox (e10s) compatibility, thank you for clearing this hurdle. To prepare for XUL/XPCOM deprecation, there are two available options, each with pros and cons:
| |
| | |
| <ol><li>'''Migrate to the Add-ons SDK''' - since WebExtensions is in development and the first release is scheduled for March 2016, one option you have is to [https://developer.mozilla.org/en-US/Add-ons/SDK migrate to the SDK].
| |
| *'''Pros:''' the APIs provided by the SDK are well-documented and are fully functional. Migrating to WebExtensions later on will be easier.
| |
| *'''Cons:''' you will need to to stick to [https://developer.mozilla.org/Add-ons/SDK/High-Level_APIs high-level APIs], which are e10s compatible and are more likely to have an equivalent WebExtensions API. You will have to migrate again once WebExtensions are fully ready, though it may be easier if you’ve already migrated to the SDK.</li>
| |
| | |
| <li>'''Migrate to WebExtensions''' - to avoid having to migrate to SDK and then again to WebExtensions, you can [https://developer.mozilla.org/Add-ons/WebExtensions migrate directly to WebExtensions].
| |
| *'''Pros:''' you only have to migrate once.
| |
| *'''Cons:''' WebExtensions may not have all the APIs you need yet, so you might have to limit the functionality of your add-on until they become available. Please [http://bit.ly/webextensions-apis tell us] which APIs you need.
| |
| </li>
| |
| </ol>
| |
|
| |
|
| =Managing the Impact= | | =Managing the Impact= |
Upcoming Changes in Add-on Development
There are a lot of changes coming up for add-on development. By the end of 2017, we will transition to WebExtensions as the standard for creating add-ons. Over the same period of time, existing methods for add-on development such as XUL/XPCOM will be deprecated. Multi-process Firefox (aka Electrolysis, or e10s) is also rolling out, which means some add-on developers will have to update their add-ons more than once.
This page contains timelines and resources to help ease the transition for add-on developers. If you're a new developer and would like create an add-on, please head over to MDN.
What's New
- Check out the new lookup tool, which you can use to see if you will be affected by the upcoming changes.
- Example add-ons created with WebExtensions APIs
- The WebExtensions survey is live! Please use this survey to tell us which APIs you need so we can better prioritize them.
Timeline of Changes
See a graph of upcoming changes, organized by Firefox release dates.
Developers who are affected by the changes
Please see the MDN article on "Working with multiprocess Firefox" for suggestions on adapting to multiple processes.
Managing the Impact
- Tell us which APIs you need - We are making the process of providing needed APIs as open as possible. Please use this survey to tell us which APIs you need in WebExtensions. This will help us prioritize and plan for what we need to support.
- WebExtensions Experiments (formerly Native.js) - We want to give developers a way to develop and experiment with APIs that go beyond what Chrome provides. To get involved, read about the project here and the corresponding criteria for evaluating new APIs.
- Transition API proposal - There is also a proposal to allow SDK add-ons to access WebExtension APIs in order to ease the transition. You can take a look and add comments here.
It is possible that not all add-ons will be able to migrate to WebExtensions without having to drop any features. But we want to work with you to get as many add-ons migrated as possible with the functionality you created intact. We invite you to contribute to its evolution, and we look forward to working with you.
Add-on Developer Communication Calendar
This calendar includes public meetings, scheduled blog posts, office hours, release milestones that affect add-on developers, and more. Links to add it to your own calendar: iCal | HTML
Blog Posts and Other Resources
WebExtensions
Multiprocess (e10s) Firefox Compatibility
Migrating from XUL/XPCOM
Get in Touch
- IRC:
- #teamaddons: team chat
- #addons: support for extensions, themes, plugins and addons.mozilla.org
- #amo: addons.mozilla.org bugs and development
- #amo-editors: add-on reviews and policy
- #extdev: extension development
- #themedev: theme development
- #webextensions: web extensions