WebExtensions/FAQ: Difference between revisions

Jump to navigation Jump to search

WebExtensions/FAQ (view source)

Revision as of 23:21, 10 November 2017

3,520 bytes removed ,  10 November 2017
Updated
(Updated)
Line 1: Line 1:
== Developing with WebExtensions ==
==Understanding the WebExtensions API==


These FAQs cover development with WebExtensions and was started in July 2016.
===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.


These FAQs are in '''draft''' status.
===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.


=== Is it multiprocess Firefox compatible? ===
==Developing with the WebExtensions API==


Yes, all APIs work with multi process Firefox and are marked as compatible by default.
===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.


=== Are they compatible with Chrome and Opera? ===
===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 WebExtensions]. It provides a quick overview to get you started as well as complete reference documentation for the entire WebExtensions API.


Mostly. We strive for compatibility to make developers lives easier and are participating in a W3C community group to work on a standard.
===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.


However Chrome, Firefox and Opera are different browsers and not all the APIs in one browser is even possible in another browser. For that reason there are incompatibilities and likely always be, but hopefully we can minimize those.
===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.


=== Will WebExtensions be a stable API? ===
===How can I distribute my extension?===
The WebExtensions section of MDN provides a complete guide to getting your extension approved and published.


Yes. We are currently planning a way to have an experimental track. A policy for deprecating or making backwards incompatible changes has not been decided.
==WebExtension Roadmap==


=== Can I add APIs to WebExtensions? ===
===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.


Absolutely and we encourage you to do so. If you are a legacy add-on developer and need an API, you might find adding in API not too difficult.
===Is WebExtensions a stable API?===
* Can I accomplish this another way that doesn't need an API? WebExtensions have full access to the window object meaning that all existing Web APIs are available to the developer.
Yes. Each API will be documented on MDN in regards to its standards and/or experimental status. API that are 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].
* Are there security or privacy concerns about such an API (the security team at Mozilla can help review this too)?
* Is this API going to be valuable to not just me, but also other add-ons developers? Every API we add to Firefox increases the engineering burden for the Mozilla community and removing APIs once they have landed is hard. Just like we'd think about adding in a new Web API to Firefox, we should take the time to think about exactly what we need.


If you are unsure about the above, please just file a bug in Bugzilla under Toolkit > WebExtensions and add the whiteboard tag [design-decision-needed]. This will allow it to be reviewed by the module owners and make sure it makes sense before you spend too much time on the API.
===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.


=== Will I be able to do everything I can in a legacy technology? ===
===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".


No. In the legacy technologies (extensions, bootstrapped extensions, SDK extensions) developers had access to almost everything in Firefox. This causes many problems from security and privacy concerns to technology changes throughout the Firefox stack.
===Can I prototype a new WebExtensions 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. Keep in mind, though, that the existence of an experiment doesn’t guarantee that the feature will ultimately become an official WebExtension API.


=== Will I have access to about:config or the preferences? ===
==WebExtension API and Legacy Extensions==


Very unlikely. Access to the preferences in the past has caused us problems. Multiple add-ons try to change them and conflict. There is no security limitations so low risk preferences and high risk preferences are mixed together. Sadly these have been exploited by add-on authors in the past.
===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.


The preferences though are generally a low level implementation detail. They are altered and changed frequently, with new preferences being added or just ignored quite frequently. Instead we'd rather WebExtensions focus on higher level APIs that implement specific tasks, those APIs might alter preferences, but it would be to the WebExtension API to manage that, not the WebExtension developer.
===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 [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.


=== Will I have access to about pages, with chrome_url_overrides? ===
===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.


Hopefully, but there's a few concerns here. WebExtensions exist inside a sandbox within Firefox to limit the amount of interaction with Firefox. The about pages within Firefox run with chrome privileges. We need to be careful about allowing access to those because it could be a possible escalation point for a WebExtension and a way to break out of the sandbox.
===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.


If that could be solved, then it seems possible for access to these APIs to happen.
===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.


== WebExtensions Decision ==
===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].
Some of these are relevant, but come from an FAQ around the decision to implement WebExtensions in August of 2015. They may not still be relevant.
 
=== How are you involving the community in the development of WebExtensions? ===
 
We are actively reaching out to developers to find out what APIs they need to migrate to WebExtensions. This helps us figure out which ones will help the greatest number of developers, and prioritize them accordingly. The goal is to first reach Chrome parity, then go beyond. Anyone can request a new API by [https://wiki.mozilla.org/WebExtensions/NewAPIs filing a bug].
 
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". If approved, additional information on how to write the API is included, and an advisor is assigned. Anyone who is interested in working on it can take it.
 
=== Why are these big changes needed? ===
 
We believe that moving Firefox away from XUL and XPCOM is a long-term strategic necessity. These technologies are 15 years old and no other browser uses them. It doesn't make sense for us to continue to invest in them, but at the same time our performance and security depends on them.
 
However, we can't even begin to move Firefox off of these technologies until we know how to evolve add-ons as well. We have announced WebExtensions and the deprecation as early as possible so that we can get feedback from the community on how to make the transition. We know that WebExtensions will need to be improved. We also know that XUL will continue to live in some form for a while.
 
=== It sounds like you're copying Google... ===
The Chrome extension API was designed to work well with process separation and we are taking inspiration from it and copying functionality where it makes sense. However, there will be differences, and the goal of WebExtensions is not to copy Chrome or allow Chrome extensions to run unmodified in Firefox, but to simplify cross-browser development by providing commonly-supported methods and interfaces. We won't implement all of Chrome's APIs, and Chrome is unlikely to implement some of the APIs we add. Imagine the APIs as a [https://en.wikipedia.org/wiki/Venn_diagram Venn diagram]. In the middle are cross-browser APIs for content scripts, tabs, and windows. In the Firefox side are APIs for toolbars and other UI elements. On the Chrome side are APIs for Google's cloud services.
 
=== How will WebExtensions be cross-browser if you're extending Google's API? ===
 
Unlike the web platform, we don't expect every browser to implement every aspect of WebExtensions in the same way. But, 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 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. As an example, an extension using a toolbar API might be able to fall back to a browser action API on other browsers.
 
=== What do you mean by "Extending the capabilities of Firefox to interact with web content" in your [https://wiki.mozilla.org/WebExtensions/Vision vision statement]? ===
 
It means helping people use the Web, like making it easier to browse, manage browsing, and use websites/web apps/content. Our focus with the WebExtensions API is about extending these capabilities rather than making Firefox an application platform.
 
=== Why WebExtensions and not Jetpack? ===
 
There are a number of reasons we chose to focus development on the WebExtension API. First, there are more Chrome extensions than Jetpack add-ons and more developers who will be familiar with developing WebExtensions. WebExtensions has built-in support for content blocking, which is used by many ad-blocking and anti-tracking extensions that are popular; Jetpack lacks such APIs. Jetpack won't solve the problem that add-on developers must maintain a different codebase for each browser. Basing our initial implementation of WebExtensions off of Chrome's API means that developers who stick to the common APIs will be able to work off of a common codebase, and port extensions more simply between browsers.
 
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.
 
=== Which add-ons will stop working when XUL/XPCOM is deprecated? ===
 
Many add-ons will need to be updated, and we anticipate that some will break with the transition to the new APIs. There is a risk that some add-ons may not transition if they are not maintained or have maintainers who lack the time to port their add-on.
 
We don't want to limit what add-ons can do in Firefox. We will work with every developer who is interested to make their add-on work in Firefox, and work to provide the functionality required in as many cases as possible. This process is designed to allow developers to extend Firefox in ways that are less brittle than the current XUL/XPCOM system, and to allow Firefox itself to transition away from XUL/XPCOM.
 
=== I'm writing a new extension today. What API should I use? ===
 
'''As of July 2016, we are strongly recommending WebExtensions for add-on development.'''
 
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.
 
If you're planning to write a new, Firefox-specific extension, the add-on SDK (Jetpack) may be your best option until WebExtensions matures. Jetpack 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.
 
=== Won't this limit experimentation? ===
If WebExtensions were ultimately limited to the Chrome model, it would. But we're actually designing a system providing extension authors with the flexibility to implement innovative 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 stable WebExtension API.
 
=== Why deprecate XUL now? Firefox is still using it 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.
 
=== Why keep the .xpi packaging format? ===
 
We're using JAR signing for WebExtensions, and 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, and there may be some changes to the final extension we use as we seek (and get) more feedback.
 
=== Are malicious addons really a problem? ===
 
Yes. Please read [https://blog.mozilla.org/addons/2015/04/15/the-case-for-extension-signing/ "The Case for Extension Signing"].
Mconca
12

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1183904"

Navigation menu