Add WebExtension status in add-on columns in the Add-on Manager

[davidhedlund]

A common misconception is that web extensions and Electrolysis (e10s, multiprocess) compatible add-ons are the same thing, they are not.

For example, the add-on Cookie Time is

• Not a WebExtension
• "Compatible with multiprocess." as seen on the screenshot.

Thus Add-on Compatibility Reporter should add extra text in the Add-on Manager

• Current text: "[Not] compatible with multiprocess"
• Proposed text: "[Not] compatible with multiprocess. This is [not] a web extension".

[wagnerand]

I think this is out of the scope for this add-on. The add-on is about identifying and reporting compatibility issues, not technologies. Also, space in the Add-ons Manager is quite limited, so adding an even longer text won't improve things.

[davidhedlund]

Also, space in the Add-ons Manager is quite limited, so adding an even longer text won't improve things.

Text can be shortened to simply: "Multiprocess. WebExtension"

[grahamperrin]

From Add-ons in 2017 | Mozilla Add-ons Blog (2016-11-23):

… By the end of 2017, and with the release of Firefox 57, we’ll move to WebExtensions exclusively, and will stop loading any other extension types on desktop. …

Given the enormity of the move, I was extremely surprised by the limited scope of reporting. There's no mention of the limitation (and no mention of multiprocess, Electrolysis or e10s) at https://addons.mozilla.org/firefox/compatibility_firstrun (captured in the Wayback Machine).

Where there's insufficient space for text, please:

• at least offer a yellow, amber or red alert.

Before reporting, and after

I should expect an alert for (at least) Tab Groups. A click on an alert icon might lead to https://addons.mozilla.org/firefox/addon/tab-groups-panorama/

[wagnerand]

There's no mention of the limitation (and no mention of multiprocess, Electrolysis or e10s) at https://addons.mozilla.org/firefox/compatibility_firstrun (captured in the Wayback Machine).

The add-on has no control over that page. Also, that page is supposed to explain how the add-on works. (I agree that it might be better to include it in the add-on.) For updates about add-ons, please follow our blog: http://blog.mozilla.org/addons/

[wagnerand]

Since the ask to include architecture information (i.e. whether the add-on is a WebExtension or not) has come up a couple of times, I want to explain why I think it is out of scope for this add-on:

• The add-on is meant for users to report issues they experience while using Firefox in conjunction with add-ons.
• In order to evaluate stability and functionality of add-ons in both release and development versions of Firefox, we added e10s information in the reporting. We exposed the information in the add-on, so users could easily check what state both Firefox and add-ons are in when reporting an issue, and also which of their add-ons is holding them back from using e10s.
• Architecture information is not relevant to the user when experiencing or reporting an issue (or no issue) with an add-on. Both legacy add-ons and WebExtensions work in all channels of Firefox as of now and if an add-on is broken, the underlying architecture does not really matter (for the report). In contrast to that, e10s information can be, as issues experienced can be related to e10s. Also, the rules for e10s to be enabled or not are quite complex and even vary depending on the Firefox version you use.
• We can't expect all users to be experienced or power-users, so we need to be careful when adding features. At the very least, we need to carefully explain them, as we did with e10s. Note that we actually never mention the term e10s in the add-on. We also set up online resources to explain what multiprocess even means. Available space in the Add-ons Manager is tight already and adding further information without proper UX design might do more harm than good (i.e. information overload).
• If we showed architecture information purely for informational purposes, we (currently) cannot offer the user any action to take. If an add-on is a legacy add-on, the user cannot do anything about it. Also, at least as of now, there is no action to take, since legacy add-ons currently work in all channels and will do so for months. I am hesitant to show a warning (or even error), when right now there is 1) no available action to take, 2) no need to take an action. That being said, we are working on assessing if and how we could show alternative add-ons. The work is being tracked in bug 1347317. Admittedly, there is not much public information yet, we will share more as soon as we are ready.

Right now, I'd rather see that information on AMO where we can show it for all add-ons instead of just the ones you already have installed. At some point, we will probably have to show information in Firefox (whatever that might look like), but having to install an add-on to see whether an add-on is a WebExtension or not seems weird to me.

[fanthos]

var am = Cu.import("resource://gre/modules/AddonManager.jsm", {}).AddonManager;
am.getAddonsByTypes(["extension"], (addonList) => {
    for(var addon of addonList) {
        console.log(addon.name, addon.id, addon.isWebExtension?"webe":(addon.multiprocessCompatible?"e10s":"none"));
    }
});

Run this script in Browser Console(Ctrl+Shift+J in Windows) will list all your extensions are built on WebExtension or it compatible with multiprocess or not.

[grahamperrin]

From the console:

ReferenceError: Cu is not defined

[fanthos]

In firefox 55, the addon manager page will show a label if the addon is legacy addon.

[grahamperrin]

Thanks … I couldn't recall whether the script did anything significantly different.

[davidhedlund]

Yes, just to make it clear: In Firefox 55, the Add-ons Manager page show a LEGACY label if the addon is not a fully developed WebExtension, Hybrid WebExtensions not counting.

Firefox 55.0.3 screenshot from the Add-on Manager (uBlock Origin added for test purpose)

Thank you @fanthos