MozillaZine

Experiment for Legacy addons after bootstrap.js removal

Talk about add-ons and extension development.
AlexVallat
 
Posts: 79
Joined: September 30th, 2006, 8:53 am

Post Posted May 17th, 2018, 1:36 am

Mozilla is set on removing support for bootstrap.js: #1449052, which is going to make things tricky for those of us still trying to maintain our legacy addons. In anticipation of this, I've been working on a WebExtension Experiment: LegacyHelper.

The idea is, you take your legacy bootstrapped extension and convert it into a WebExtension by adding a manifest.json and a minimal background script. The WebExtension then references the LegacyHelper Experiment API and uses it to load and run a bootstrap.js file (there are other options as well, if you just need to load a stylesheet or framescript, for example).

There are limitations, of course: Experiments can only be installed on Developer and Nightly editions with extensions.legacy.enabled set true, but that's not different to installing a legacy bootstrapped addon anyway. Unfortunately AMO won't sign an experiment, so you also need xpinstall.signatures.required set false to install the experiment. I believe that addons which merely reference experiments can still be signed, though.

I'm sure there will be more challenges ahead in maintaining a legacy addon, but this is one more tool in the box to keep them going a while longer!

pintassilgo
 
Posts: 153
Joined: August 30th, 2013, 3:50 pm

Post Posted May 17th, 2018, 8:57 pm

Great, thank you for this. I'll look into this later when I have time.

Don't you think it would be better to use AutoConfig instead of Experiments? It would certainly be harder to use with Addons Manager (autoupdates and so on, but today this doesn't matter much, since virtually no legacy addon receive updates), but I'm thinking on edge cases. After I read this:
Unfortunately, at the current time, the main window is loaded before addons have a chance to execute, so overrides will not apply to the first open window.

I think AutoConfig doesn't have this limitation. For example, is it possible to migrate Master Password+ (to ask master password before initial Firefox window shows up) (supposing it was already bootstrapped, which is not) to Experiments? I don't know, but with AutoConfig I'm almost sure yes.

AlexVallat
 
Posts: 79
Joined: September 30th, 2006, 8:53 am

Post Posted May 18th, 2018, 12:05 am

This isn't an attempt to just make old legacy addons which aren't being updated work. That's almost certainly a losing proposition, as legacy addons will require constant maintenance to keep up with changes to Firefox. It is there to provide legacy addon authors a way to keep them alive after bootstrap.js is gone.

I don't know much about AutoConfig, but I think there might be a problem there getting it to be profile-aware. If someone who does know the AutoConfig system can make it provide a service that WebExtensions can use easily to enhance themselves to legacy levels of functionality without requiring the addon author to mess about with AutoConfig themselves, that would be useful. Bonus points for some sort of easy installer for that!

pintassilgo
 
Posts: 153
Joined: August 30th, 2013, 3:50 pm

Post Posted May 18th, 2018, 9:19 am

I'm on Fx 60 DevEd (haven't yet had time to update to current 61) with dozens of legacy addons which I maintain by myself, tweaking the code to keep up with Firefox changes (some of them: legacy Greasemonkey, DownThemAll!, legacy Stylish, Save File to). Some of the simplest legacy addons I already converted to use with AutoConfig, like Enter Selects, Status Bar, Mouse Gestures, Extension Options Menu.

What userChrome.css is for CSS customization, AutoConfig is for JavaScript (userChrome.js). Currently my userChromeJS/AutoConfig manager works like UserScript metadata, but something more complex is possible, even a XPI loader.

One thing my AutoConfig fix is the support for legacy addons having their own prefs file, removed in Fx 58 (https://bugzilla.mozilla.org/show_bug.cgi?id=1413413).

Some reference (not the most updated code):
https://github.com/xiaoxiaoflood/firefox-scripts

Since my AutoConfig looks for chrome folder inside profile folder, it is profile-aware.

Today I think AutoConfig will be the only way to stay with the same level of customization that was possible with legacy addons, since Experiments seems to have some limitations.

But my knowledge and time are limited, so I'm looking for someone with the same interests.

AlexVallat
 
Posts: 79
Joined: September 30th, 2006, 8:53 am

Post Posted May 19th, 2018, 12:28 am

That's interesting, thanks for the link. It's great to know there are others who are don't accept WebExtension limitations too!

I think the AutoConfig approach is interesting, but difficult to set up. It's understandable if an initial framework is a difficult install, or requires an installer or script or something to set up, but I think after the framework has been installed there ought to be an easy UI way to add or remove addons that depend on it.

pintassilgo
 
Posts: 153
Joined: August 30th, 2013, 3:50 pm

Post Posted May 19th, 2018, 2:51 pm

Considering its power, anything is possible, if there is someone with knowledge and willingness.

For now I can enable/disable/reload/uninstall any userChromeJS script from the toolbar button. And when the browser try to open a .uc.js file, a warning allows automatic installation (like what UserScript managers do with user.js files).
Image

And also this one, which I honestly don't use, I prefer to use the toolbar button. I could easily add button to remove.
http://i.imgur.com/HsXa8Bz.png
http://i.imgur.com/qBIxJ8q.png

Return to Extension Development


Who is online

Users browsing this forum: No registered users and 1 guest