Changes

These FAQs cover development with WebExtensionsand was started in July 2016. '''[draft]''' == Is it multi-process Firefox compatible? == Yes, all APIs work with multi process Firefox and are marked as compatible by default. == Are they compatible with Chrome and Opera? == Mostly. We strive for compatibility to make developers lives easier and are participating in a W3C community group to work on a standard. 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. == Will WebExtensions be a stable API? == 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. == Can I add APIs to WebExtensions? == 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.* 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.* 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. == Will I be able to do everything I can in a legacy technology? == 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. == Will I have access to about:config or the preferences? == 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. 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. == Will I have access to about pages, with chrome_url_overrides? == 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. If that could be solved, then it seems possible for access to these APIs to happen.