MozillaWiki

WebExtensions/FAQ: Difference between revisions

< WebExtensions
(remove question)
(added link to proposed deprecation policy page, now that I know it exists)
 
(24 intermediate revisions by 8 users not shown)
Line 1: Line 1:
=== It sounds like you're copying Google.... ===
==Understanding the WebExtensions API==
The Chrome extension API was designed to work well with process separation and we are certainly taking inspiration from it and copying functionality where it makes sense. In other areas it doesn't.
=== How will the WebExtensions API be different from the Chrome Extension API===
You could imagine a Venn Diagram of the two extension APIs. One circle is Chrome's, the other WebExtensions. The overlapping are are basic extension functionality (''give some examples'').


Outside of that overlap area would be the areas of differentiation. For example, we don't have much interest in providing easy access to Google's services though WebExtensions. We do however want to support certain use cases that don't seem to be a priority for Google. We have identified a few such areas that we want to support such as ad-blocking, tab management, UI modification and time/location shifting content.
===What is an extension?===
An extension is a structured collection of web development code (JavaScript, HTML, CSS) that modifies the behavior or appearance of the Firefox browser. Extensions have been a part of Firefox for many years and allow users to customize their browsing experience.


=== Why WebExtensions and not Jetpack? ===
===What is the WebExtensions API?===
WebExtensions is the name of the API used to write extensions for Firefox. Large portions of it are compatible with the API for Chrome, Opera and MS Edge so that extensions can more easily be created and used across browser platforms.


There are several reasons why we chose to start with Chrome's API. First, there are more extensions already written for it and more developers familiar with it. Second, it has built-in support for content blocking, which Jetpack lacks. These content blocking APIs are used by a lot of ad blocking and anti-tracking add-ons, which are some of the most popular.
==Developing with the WebExtensions API==


In Jetpack's favor, it has a powerful module system similar to the one in node.js. However, given that JavaScript will soon have built-in support for modules, this won't be an advantage for long.
===What skills are needed to write an extension with the WebExtensions API?===
If you know HTML, CSS and some JavaScript, you have all the necessary skills to write a Firefox extension. The WebExtensions API is designed to be easily understood and used by anyone using modern web development tools.


Finally, Jetpack doesn't solve the problem that add-on developers must code for two very different APIs. Basing WebExtensions off Chrome's API means that developers who stick to the common APIs will only have to maintain one codebase.
===I want to write an extension. Where do I start?===
The MDN web docs site has an [https://developer.mozilla.org/en-US/Add-ons/WebExtensions entire section] dedicated to extension development with the WebExtensions API. It provides a quick overview to get you started as well as complete reference documentation for the entire WebExtensions API.


=== How will WebExtensions be cross-browser if you're extending Google's API? ===
===Are WebExtension API compatible with multiprocess Firefox?===
Yes, all APIs work with multiprocess Firefox and are marked as compatible by default. No special development steps are needed.


Unlike the web platform, we don't expect every browser to implement every aspect of WebExtensions in the same way. Hopefully there will be APIs that all browsers agree on, and they will work essentially the same way in all browsers. But there will also be APIs that are more browser-specific. For example, it's unlikely that Chrome will ever support a toolbar API, but Firefox probably will.
===Does the WebExtensions API provide access to preferences?===
No. Direct access to preferences in the past has caused many problems. Multiple extensions would try to change them and conflict, and the lack of security limitations meant malicious extensions were able to take advantage of users. Instead, WebExtensions focus on higher level APIs that implement specific tasks. Those APIs may subsequently alter preferences, but the WebExtension API would manage that behind the scenes, the developer would not set them directly.


Even without perfect compatibility between browsers, a common API still has many advantages for extension developers. If developers stay within the common API, their extensions will automatically work across browsers. Even if developers choose to use browser-specific APIs, their extensions may be usable on other browsers through feature detection and fallbacks. For example, an extension using a toolbar API might be able to fall back to the browser action API on other browsers.
===How can I distribute my extension?===
The [https://developer.mozilla.org/Add-ons/Distribution Publishing and Distributing] section of MDN provides a complete guide to getting your extension approved and published.


=== Which add-ons will stop working after the deprecation? ===
==WebExtension Roadmap==


We don't want to limit what add-ons can do in Firefox. The process we've started is designed to understand how we can extend Firefox in ways that are less brittle than the current XUL/XPCOM system. We will work with every developer who is interested to make their add-on work in Firefox. That said, add-ons may be lost if they are unmaintained or have maintainers who lack the time to port their add-on.
===Is the WebExtensions API a Web standard?===
Not yet. Working through a [https://www.w3.org/community/browserext/ W3C charter group], Mozilla has partnered with Microsoft and Opera to define a browser extension API that works across multiple browsers. There is currently a [https://browserext.github.io/browserext/ preliminary specification] that matches what Google has implemented in Chrome so that extensions written to the specification could potentially work on Chrome, Edge, Opera and Firefox.
For the moment, however, there are still differences between browsers that developers need to be aware of.  The preliminary specification defines the browser extension namespace as “browser” whereas Chrome defines it as “chome.” Firefox supports both namespaces in order to enable a larger population of current extensions. In addition, a [https://github.com/mozilla/webextension-polyfill WebExtensions polyfill] exists that will allow extensions written to the preliminary specification to work in Chrome.


=== I'm writing a new extension today. What API should I use? ===
===Is WebExtensions a stable API?===
Yes. Each API will be documented on MDN in regards to its standards and/or experimental status. APIs that are [[WebExtensions/DeprecationPolicy|deprecated will also be noted]]. More details on how to understand the status of the WebExtensions API can be found on the [https://wiki.mozilla.org/WebExtensions/Spec wiki page].


That's a complex decision. If you already have a Chrome extension, it's probably best to wait until WebExtensions are ready for general purpose use. We expect that to take a few more months. You can consult the [[WebExtensions|WebExtensions wiki]] to see whether the APIs you're using are supported or whether they're likely to be supported in the future.
===Are there WebExtension API outside of the draft specification?===
Yes. Unlike the web platform, we don't expect every browser to implement every aspect of WebExtensions in the same way. However, even without perfect overlap between browsers, a common API still has many advantages for extension developers. If developers stay within the common API, their extensions should work with minimal (or no) modifications across browsers. Even if developers choose to use browser-specific APIs, their extensions may be usable on other browsers through feature detection and fallbacks.


If you're planning to write a new, Firefox-specific extension, the add-on SDK (Jetpack) may be your best option. It is well supported in older versions of Firefox and is well-documented. However, make sure to read [https://developer.mozilla.org/en-US/Add-ons/SDK/Guides/Multiprocess_Firefox_and_the_SDK "Multiprocess Firefox and the SDK"] to ensure your add-on is compatible with Electrolysis.
===Can I propose a new API for WebExtensions?===
Absolutely, and we encourage you to do so.  Before starting, consider whether your proposed API fits within the [[WebExtensions/policy|WebExtensions API Policy]]. If it does, file a bug in Bugzilla under Toolkit -> WebExtensions: Untriaged. This allows the proposal to be reviewed by the WebExtensions development team. To make the decision process as transparent as possible, we hold a [https://wiki.mozilla.org/Add-ons/Contribute/Triage public triage] of these bugs every other week. Each one is labeled "design needed", "approved", or "rejected".


=== Won't this limit experimentation? ===
===Can I prototype a new WebExtensions API?===
As is, it will. We are trying to devise a system that will allow for extension authors to have the flexibility to implement features that the WebExtension API doesn't currently allow. [https://discourse.mozilla-community.org/t/proposal-native-js-to-embrace-extend-the-webextensions-api/3457 Some discussion] has already begun. The intent is for add-on authors to experiment through this mechanism with the knowledge that there are no guarantees of compatibility between Firefox releases and use that to inform future additions to the WebExtension API
Yes. [https://webextensions-experiments.readthedocs.io WebExtension Experiments] allow you to expose and test almost any feature as a new WebExtensions API without having to build Firefox. It can help you understand how an API might work and what its limitations might be. Prototype WebExtension experiments can be run in the Firefox [https://www.mozilla.org/firefox/channel/desktop/ Nightly] build. Keep in mind, though, that the existence of an experiment doesn’t guarantee that the feature will ultimately become an official WebExtension API.


=== I already have a XUL extension. How is this not terrible news for me? ===
==WebExtension API and Legacy Extensions==


There is certainly some short term pain that we're inflicting, but we hope that the long term gains are worth it. In the short term (~18 months) you will need to rewrite your add-on to use the new APIs. However, after that, you're done! The intention is for the WebExtension API to be stable enough that addon authors can rely on it not to break between Firefox releases.
===When did Firefox adopt the WebExtensions API?===
In August of 2015, [https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/ Mozilla announced] that the legacy XPCOM- and XUL-based extension systems would be deprecated in favor of the WebExtension API. Between that date and November, 2017, both legacy and WebExtension add-ons were supported in some fashion. With the release of Firefox 57 (Quantum) in November, 2017, WebExtensions became the only supported API for extension development.


=== Why deprecate XUL now? Firefox is still using it internally. ===
===Doesn’t Firefox use XUL internally?===
Yes, Firefox is using XUL internally right now. But, Firefox is actively planning for the removal of XUL internally. That will translate into death by 100s of paper cuts (i.e. breakage with every release) for addons that depend on Firefox's usage of XUL as it is progressively removed from the product.
There are parts of Firefox that continue to use XUL internally. Over time, though, XUL is being actively replaced with newer, more modern technologies. For example, starting with release 57 (Quantum), Firefox has an entirely [https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/ new CSS engine]. The WebExtensions API creates a layer of abstraction between an extension and the internal technologies used by Firefox. Extensions that depended on Firefox's usage of XUL would eventually break as XUL is progressively removed from the product.


=== Why keep the .xpi packaging format? ===
===Did Firefox copy Google Chrome?===
=== It sounds like you've made decisions without community input ===
The goal of the WebExtensions API was not to simply copy Chrome or even allow Chrome extensions to run unmodified in Firefox, but to simplify cross-browser development by providing commonly-supported methods and interfaces. To deny that Chrome had a very large market share and a modern, supportable extension ecosystem would have been foolish. Providing open, cross-platform interoperability on the web is central to Mozilla’s mission, so modeling the WebExtensions API on Chrome’s existing API made the most sense for the internet. That said, each vendor will have certain API that only apply to their own browsers.
We're just getting started with WebExtensions, and have begun with a set of APIs that are commonly used with Chrome so people can kick the tires. We don't want to be a Chrome copy, and want to ensure we differentiate while integrating Electrolysis and other initatives into Firefox. To innovate will require input and assistance from the community, which we are actively seeking. The path for WebExtensions will evolve in the coming weeks, months, and years, and we want the developer community to be a big part of that evolution.
 
=== Are malicious addons really a problem? ===
===Why WebExtensions and not Jetpack?===
Yes. Please read [https://blog.mozilla.org/addons/2015/04/15/the-case-for-extension-signing/ "The Case for Extension Signing"].
The WebExtensions API has some inherent technology advantages, such as built-in support for content blocking used by popular ad-blocking extensions, that Jetpack lacked. More importantly, though, basing the initial implementation of WebExtensions on Chrome's API meant that Firefox could leverage a large population of Chrome extensions (larger than Jetpack add-ons) and extension developers. Those developers who stayed with the common APIs were also able to work off of a common codebase, and port extensions more simply between browsers.
 
===Why keep the .xpi packaging format?===
Firefox uses JAR signing for WebExtensions while Chrome uses a different system. Since signing is necessarily browser-specific, integrating the two would be difficult, and maintaining the current packaging extension for Firefox makes sense. The only part of the XPI file format that WebExtensions uses is the filename suffix.
 
===Were malicious add-ons really a problem?===
Yes. Please read [https://blog.mozilla.org/addons/2015/04/15/the-case-for-extension-signing/ The Case for Extension Signing].

Latest revision as of 02:09, 5 September 2018

Understanding the WebExtensions API

What is an extension?

An extension is a structured collection of web development code (JavaScript, HTML, CSS) that modifies the behavior or appearance of the Firefox browser. Extensions have been a part of Firefox for many years and allow users to customize their browsing experience.

What is the WebExtensions API?

WebExtensions is the name of the API used to write extensions for Firefox. Large portions of it are compatible with the API for Chrome, Opera and MS Edge so that extensions can more easily be created and used across browser platforms.

Developing with the WebExtensions API

What skills are needed to write an extension with the WebExtensions API?

If you know HTML, CSS and some JavaScript, you have all the necessary skills to write a Firefox extension. The WebExtensions API is designed to be easily understood and used by anyone using modern web development tools.

I want to write an extension. Where do I start?

The MDN web docs site has an entire section dedicated to extension development with the WebExtensions API. It provides a quick overview to get you started as well as complete reference documentation for the entire WebExtensions API.

Are WebExtension API compatible with multiprocess Firefox?

Yes, all APIs work with multiprocess Firefox and are marked as compatible by default. No special development steps are needed.

Does the WebExtensions API provide access to preferences?

No. Direct access to preferences in the past has caused many problems. Multiple extensions would try to change them and conflict, and the lack of security limitations meant malicious extensions were able to take advantage of users. Instead, WebExtensions focus on higher level APIs that implement specific tasks. Those APIs may subsequently alter preferences, but the WebExtension API would manage that behind the scenes, the developer would not set them directly.

How can I distribute my extension?

The Publishing and Distributing section of MDN provides a complete guide to getting your extension approved and published.

WebExtension Roadmap

Is the WebExtensions API a Web standard?

Not yet. Working through a W3C charter group, Mozilla has partnered with Microsoft and Opera to define a browser extension API that works across multiple browsers. There is currently a preliminary specification that matches what Google has implemented in Chrome so that extensions written to the specification could potentially work on Chrome, Edge, Opera and Firefox. For the moment, however, there are still differences between browsers that developers need to be aware of. The preliminary specification defines the browser extension namespace as “browser” whereas Chrome defines it as “chome.” Firefox supports both namespaces in order to enable a larger population of current extensions. In addition, a WebExtensions polyfill exists that will allow extensions written to the preliminary specification to work in Chrome.

Is WebExtensions a stable API?

Yes. Each API will be documented on MDN in regards to its standards and/or experimental status. APIs that are deprecated will also be noted. More details on how to understand the status of the WebExtensions API can be found on the wiki page.

Are there WebExtension API outside of the draft specification?

Yes. Unlike the web platform, we don't expect every browser to implement every aspect of WebExtensions in the same way. However, even without perfect overlap between browsers, a common API still has many advantages for extension developers. If developers stay within the common API, their extensions should work with minimal (or no) modifications across browsers. Even if developers choose to use browser-specific APIs, their extensions may be usable on other browsers through feature detection and fallbacks.

Can I propose a new API for WebExtensions?

Absolutely, and we encourage you to do so. Before starting, consider whether your proposed API fits within the WebExtensions API Policy. If it does, file a bug in Bugzilla under Toolkit -> WebExtensions: Untriaged. This allows the proposal to be reviewed by the WebExtensions development team. To make the decision process as transparent as possible, we hold a public triage of these bugs every other week. Each one is labeled "design needed", "approved", or "rejected".

Can I prototype a new WebExtensions API?

Yes. WebExtension Experiments allow you to expose and test almost any feature as a new WebExtensions API without having to build Firefox. It can help you understand how an API might work and what its limitations might be. Prototype WebExtension experiments can be run in the Firefox Nightly build. Keep in mind, though, that the existence of an experiment doesn’t guarantee that the feature will ultimately become an official WebExtension API.

WebExtension API and Legacy Extensions

When did Firefox adopt the WebExtensions API?

In August of 2015, Mozilla announced that the legacy XPCOM- and XUL-based extension systems would be deprecated in favor of the WebExtension API. Between that date and November, 2017, both legacy and WebExtension add-ons were supported in some fashion. With the release of Firefox 57 (Quantum) in November, 2017, WebExtensions became the only supported API for extension development.

Doesn’t Firefox use XUL internally?

There are parts of Firefox that continue to use XUL internally. Over time, though, XUL is being actively replaced with newer, more modern technologies. For example, starting with release 57 (Quantum), Firefox has an entirely new CSS engine. The WebExtensions API creates a layer of abstraction between an extension and the internal technologies used by Firefox. Extensions that depended on Firefox's usage of XUL would eventually break as XUL is progressively removed from the product.

Did Firefox copy Google Chrome?

The goal of the WebExtensions API was not to simply copy Chrome or even allow Chrome extensions to run unmodified in Firefox, but to simplify cross-browser development by providing commonly-supported methods and interfaces. To deny that Chrome had a very large market share and a modern, supportable extension ecosystem would have been foolish. Providing open, cross-platform interoperability on the web is central to Mozilla’s mission, so modeling the WebExtensions API on Chrome’s existing API made the most sense for the internet. That said, each vendor will have certain API that only apply to their own browsers.

Why WebExtensions and not Jetpack?

The WebExtensions API has some inherent technology advantages, such as built-in support for content blocking used by popular ad-blocking extensions, that Jetpack lacked. More importantly, though, basing the initial implementation of WebExtensions on Chrome's API meant that Firefox could leverage a large population of Chrome extensions (larger than Jetpack add-ons) and extension developers. Those developers who stayed with the common APIs were also able to work off of a common codebase, and port extensions more simply between browsers.

Why keep the .xpi packaging format?

Firefox uses JAR signing for WebExtensions while Chrome uses a different system. Since signing is necessarily browser-specific, integrating the two would be difficult, and maintaining the current packaging extension for Firefox makes sense. The only part of the XPI file format that WebExtensions uses is the filename suffix.

Were malicious add-ons really a problem?

Yes. Please read The Case for Extension Signing.

Retrieved from "https://wiki.allizom.org/index.php?title=WebExtensions/FAQ&oldid=1200561"