WebExtensions/Future

This page discusses the possible expansion of the WebExtensions API to support more add-on use cases.

Please see the uservoice page for requests from developers.

One of the goals here is to open up new possibilities for extensions. We want to create the sort of vibrant new community that has formed around Atom packages.

Priorities

• Extensions shouldn't randomly break due to small changes in the browser
• Two extensions should compose well (i.e., not break when both are installed)
• Users should always be aware when an extension is modifying the UI
• Ideally, APIs should make sense in all browsers, not just Firefox
• APIs should be easy to use

Interesting Add-ons

• Tree Style Tab
• NoScript
• Vimperator/Pentadactyl
• Tab Mix Plus
• FireGestures
• Classic theme restorer
• DownThemAll
• CCK

Additional APIs

These APIs would work just like other WebExtension APIs.

• NoScript-type functionality. This would come in the form of extensions to webRequest and possibly contentSettings.
• Sidebars. Opera already supports sidebar functionality; Chrome may soon. We would like to be able to implement Tree Style Tabs or Vertical Tabs by hiding the tab strip and showing a tab sidebar.
• Toolbars. Firefox has a lot of existing toolbar add-ons.
• Better keyboard shortcut support. We'd like to support Vimperator-type functionality.
• Ability to add tabs to about:addons.
• Ability to take images of frames/tabs (like canvas.drawWindow)
• Ability to overlay the entire browser window with some HTML (which might be partially transparent).
• Change tab colors, set badges for tabs.

Extension Points

If we're going to support the functionality in add-ons like Tab Mix Plus and the CCK, we're probably going to need to add a good number of "extension points" throughout the browser frontend code. These would allow WebExtensions to modify basic behaviors like opening/closing tabs, clicking on links, and entering things in the URL bar.

Some of these could act like prefs, just enabling or disabling certain optional behaviors. In other cases, we might want the extension to be able to run a callback and make a decision in realtime. Unfortunately, doing so would require an async call into the add-on process, so it's not something we should do lightly. However, I suspect that the users of these add-ons are more than willing to accept the performance hit.

"Superpowers"

This section proposes some more significant additions to WebExtensions. These are things people are likely to ask for. We need to decide whether they make sense.

• Bundling of NPAPI plugins with extensions.

• Bundling of native executables with extensions. The connectNative API would be used to connect to the app. Chrome requires the executable to be shipped separately.

• Bundling and use of js-ctypes libraries with extensions. The code would be loaded into the add-on process (once we implement out-of-process WebExtensions). We could choose whether to sandbox the process or not. The DLL could be loaded before entering the sandbox.

• Permission to use js-ctypes from the chrome process. [1]

• Giorgio's native.js proposal, which would allow some WebExtensions to continue to use XUL/XPCOM through an asynchronous message channel. This would probably require a special review process, a time limit, or a way of deprecating XPCOM APIs within native.js over time. Another related proposal is to force the XUL/XPCOM stuff to happen in an entirely separate add-on that would have no inherent functionality of its own.