1223642 - It should be possible for webextensions to extend other webextensions

Status: RESOLVED WONTFIX

(WebExtensions :: Untriaged, defect)

Description

[Erik Vold]

With old school and sdk based add-ons it was possible for an add-on like Add-Art to extend another add-on like Adblock Plus.  Another example is Greasefire extending Greasemonkey.

This should continue to be possible, or else many add-ons that currently exist will not be able to be supported by webextensions which is something Mozilla seems to be claiming it doesn't want to do, somehow.

For this to work in the webextensions walled garden, the add-on which is being extended needs to be able to provide some sort of async api to other add-ons so that those other add-ons may extend it.  These add-on apis can be built on the observer service, I created the addon-communication sdk module for this in the past.

Obviously an add-on dev will want to be able to test, with automated tests, that these add-on extension apis work for other add-ons that extend them.  So I would think that it should be easy to write a test which installs another add-on which would extend the add-on which is being developed.  In other words Adblock plus should be easily able to write a test that shows it is extendable for another add-on like Add-Art.  This is simple to do now with add-ons based on the Add-on SDK (unless require('chrome') is removed without enough api to replace it for this purpose).

I hope Mozilla continues to support the ability to test add-ons as easily as I had made it for Add-on SDK add-ons with jpm while I was able to work at Mozilla.

Comment 1

[Blake Winton (:bwinton) (:☕️)]

James had some ideas along these lines, and there's also the Atom editor’s Services as prior art at https://atom.io/docs/v1.1.0/behind-atom-interacting-with-other-packages-via-services .

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

Does "Cross-extension messaging" https://developer.chrome.com/extensions/messaging#external cover this?

Comment 3

[Erik Vold]

Note: One of the top 10 Firefox add-ons on AMO is an extension which extends Adblock Plus

https://addons.mozilla.org/en-US/firefox/addon/adblock-plus-pop-up-addon/?src=hp-dl-mostpopular

Comment 4

[James Hugman [:jhugman] [@jhugman]]

I've written about a couple of other use cases[1] on my blog. That post takes the idea far further than it needs to go so jump out whenever you've had enough. 

I've also developed those ideas, and have a fairly principled implementation[2] of this, requiring three extra manifest entries. The one not mentioned in the blog post was a way of adding to the APIs available through the permissions system. This, I think, is the what #0 is asking for.

It covers the pertinent use cases: 
  * I want to use a fully configured object that another addon provides.
  * I want to provide an extender-thing to another addon. 

It works beautifully for building node apps and is a lot of fun to build remixable servers, console apps (i.e. it runs its own prompt), and command-line apps.

It's very OSGi/Eclipse influenced, and it explicitly builds atop npm.

Unexpectedly, it is also really fun to use.

Linking to this post[3] in the dev-addons which gives another couple of use cases and some existing discussion.

[1] http://www.jhugman.com/2015/addonception-addons-extending-addons
[2] https://github.com/jhugman/compo
[3] https://mail.mozilla.org/pipermail/dev-addons/2015-October/000071.html

Comment 5

[:shell escalante]

put ? to discuss at triage and evaluate effort / impact of fixing on adblock plus pop up (1M)

Comment 6

[Andy McKay]

There are multiple things an add-on can do:
* write their JS code in a library that can be pulled into any add-on, e.g: through npm
* implement https://developer.chrome.com/extensions/messaging#external as suggested by asuth in bug 1253643
* if the API is one that other add-ons might want to use, push down into the native.js path as being trialed by https://wiki.mozilla.org/WebExtensions/Experiments

With those things in place, or in progress, I'm not convinced at this time we need to go beyond that. Is there something I'm missing?

Comment 7

[YUKI "Piro" Hiroshi]

I also agree to the decision "WONTFIX", WebExtensions-based addons should communicate and collaborate with public APIs instead of monkey patching. Otherwise, unnecessary deadlock will happen - if an addon stops its update and another one creates an another addon to extend the original with such dirty way, and the original author restarts his activities, then he will suffered from compatibility problems of breakage around the third-party extender addon.

Comment 8

[James Hugman [:jhugman] [@jhugman]]

I've got an experiment started on this in a side project, but RL has caught up with me.