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.

Standard 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)

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.