WebExtensions/Future - Revision history

Wmccloskey: switched order

2015-08-22T17:43:28Z

switched order

@@ Line 4: / Line 4: @@
 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.
 == Interesting Add-ons ==
@@ Line 15: / Line 23: @@
 * DownThemAll
 * CCK
 == Additional APIs ==

Wmccloskey: list of addons, priorities

2015-08-22T16:35:42Z

list of addons, priorities

@@ Line 3: / Line 3: @@
 Please see the [https://webextensions.uservoice.com/forums/315663-webextension-api-ideas uservoice page] for requests from developers.
-== Standard APIs ==
+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.
 These APIs would work just like other WebExtension APIs.
@@ Line 13: / Line 35: @@
 * Ability to add tabs to about:addons.
 * Ability to take images of frames/tabs (like canvas.drawWindow)
 == Extension Points ==

Wmccloskey: uservoice link

2015-08-22T03:19:05Z

uservoice link

← Older revision		Revision as of 03:19, 22 August 2015
Line 1:		Line 1:
	This page discusses the possible expansion of the WebExtensions API to support more add-on use cases.		This page discusses the possible expansion of the WebExtensions API to support more add-on use cases.

			Please see the [https://webextensions.uservoice.com/forums/315663-webextension-api-ideas uservoice page] for requests from developers.

	== Standard APIs ==		== Standard APIs ==

Wmccloskey: Initial version

2015-08-22T03:16:10Z

Initial version

New page

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

== 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 [https://developer.chrome.com/extensions/nativeMessaging 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. [https://pastebin.mozilla.org/8843469]

* 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.