Make extension Electrolysis compatible

Add-ons Development
#1

Hi,

me and my team have developed a bootstrap firefox extension. After this announcement https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/ we need to make it Electrolysis compatible.

In above link it is stated that WebExtensions are fully compatible with Electrolysis, so my question is should we refactor our code to use WebExtensions API so that it is automatically Electrolysis compatible or should we use the “message-manager” technique to load a frame script into the current browser? Is there any other technique for a bootstrapped extension?

My concern is that WebExtensions API is still under development, so what if Electrolysis is being released and some WebExtensions APIs are still not supported? What’s the way to go? I guess we could use a hybrid architecture, right? Can you provide any links to an already ported real example?

Thanks,
Panagiota

#2

Probably not a good idea yet. WebExtensions are only available starting with Firefox 42 (not released yet) and they are still far from being mature. Are we Web Extensions yet? lists plenty of known issues even in the commonly used APIs, and the list of issues is expected to grow significantly as people start to try it out for real. I fully expect WebExtensions to take at least a year to become really usable, Electrolysis will be enabled by default much sooner than that.

Frame scripts aren’t very intuitive but they are definitely going to work, that API has been available for a long time. Starting with Firefox 38 you can also use process scripts - depending on the use case it might be more efficient (one instance of the script per Firefox process as opposed to one instance for each tab). The big disadvantage: at some point this code will have to be thrown away and rewritten, as Mozilla decides to deprecate classic extensions.

There is an alternative: the Add-on SDK (at least the high-level APIs) also supports Electrolysis automatically, and it is already mature enough to be used. Also, Mozilla promised to keep supporting the high-level APIs of the Add-on SDK. So if your extension can be implemented with the high-level APIs (or minimal usage of low-level APIs that you could probably replace by something else if necessary) then the Add-on SDK should be the way to go right now.

#3

I found what made framescript, and chromeworker, messaging super easy for me, is creating functions on both sides which can call “functions” in the other side. Then setup a callback to run. And the other side can return a promise if they aren’t doing sync stuff.

Its not so intuitive how i did things but once you figure it out its super easy, you can make your own version too. This is my framescript communication “api”: https://gist.github.com/Noitidart/03c84a4fc1e566bd0fe5

You can see me using it here: https://addons.mozilla.org/en-US/firefox/addon/tweeeeeeeeeeeeeeeeeeter/ and i can give you more examples if you want to see this for inspiration or using it yourself.

#4

Perhaps the first question is what your addon does that is incompatible with electrolysis. Access to content DOM from chrome is the most obvious, but there are other things too like events that don’t cross from content to chrome, some notifications that you no longer get in chrome, etc. If you already use content scripts then they should be fine. A frame script is like a content script, but it has chrome privileges although some things it can’t do, like File IO.

Currently, the default assumption is that an addon is not compatible unless it explicitly sets a flag to say it is. Non-compatible addons automatically get a shim created for every content object, and it becomes a Cross Process Object Wrapper (CPOW). When a CPOW is accessed, behind the scenes a message is sent to the content process and the result returned to you. Just as if content was still there, but an awful lot slower. In most cases, a message will appear in the console saying “unsafe CPOW access”. Your addon may work, that is the whole point of the shims. You should probably still consider moving those accesses into frame scripts, but it isn’t so time critical. Once you set your flag to say your addon is compatible, then all the shims become null. A good way to test if you really are compatible! You may come across more subtle problems related to timing of access to things that used to be synchronous, but now aren’t.

Once you know what you need to change, then you can decide how to go about it. WEAPI probably isn’t going to be possible at this point. The SDK might be a possibility.

#5

Hi Wladimir,

thanks for your answer. I will start making our extension Electrolysis compatible with a messaging technique. In the meanwhile, I’ll experiment writing a WebExtension version.

I would like a clarification regarding this:

As I mentioned we use the bootstrapped version, so I guess it doesn’t make sense to switch from bootstrap to Add-on SDK (our codebase is already big and we had our reasons to use former versus latter).

So, I am trying to understand how a hybrid architecture with a manifest & bootstrap file could work. I already found https://bugzilla.mozilla.org/show_bug.cgi?id=1215048 (created actually by you :slight_smile: ), which might be related. To my understanding, we have a bootstrap file and manifest.json is loaded on the fly?

I have some more questions regarding WebExtensions and lazy loading of multiple background scripts, but I’ll better create a seperate post for this.

#6

Continuing the discussion from Make extension Electrolysis compatible:

Thanks for the link and the Tweeeeeeeeeeeeeeeeeeter example, I’ll have a look:-)

#7

Yep, exactly! Thanks for explanation. I’ll follow https://developer.mozilla.org/en-US/Add-ons/Working_with_multiprocess_Firefox and proceed with necessary changes.

#8

The difference is that Mozilla promised to keep extensions based on Add-on SDK working. “Regular” bootstrapped extensions on the other hand will be disabled at some point. I’m not saying that moving to the Add-on SDK no matter what is the right decision, e.g. extensions that require lots of low-level modules won’t be in any better position after the move - it’s merely an option worth considering.

Concerning the “hybrid” approach, I posted my findings under https://palant.de/2015/10/15/using-webextensions-apis-in-a-classic-extension. However, I wouldn’t consider it practicable at this point.

Hybrid extension/ bootstrapped & WebExtensions
#9

Do you have a link to this?

#10

Yes, in the original announcement:

Add-ons based on the Jetpack SDK will work well as long as they don’t use require(‘chrome’) or some of the low-level APIs to touch objects in the content process.

…

We will also continue supporting SDK add-ons as long as they don’t use require(‘chrome’) or some of the low-level APIs that provide access to XUL elements.

And then in the comments:

There are no plans to deprecate the Addon SDK in its current form at
this time. It’s already Electrolysis compatible (although, per above,
the use of require(‘chrome’) will not be supported). However, we expect
that most of our effort will be directed towards extending WebExtensions
to meet developer’s needs. Some of these APIs may be ported to Jetpack
as needed, but WebExtensions will be our favored platform.

IMHO this should be read as “there is no future for the SDK but we’ll keep it alive for a while.”

#11

I didn’t read it like that at all.

Add-ons based on the Jetpack SDK will work well as long as they don’t use require(‘chrome’) or some of the low-level APIs to touch objects in the content process.

I’m almost sure that this bit is relative to e10s compatibility only, meaning the SDK will work in e10s-enabled builds; it seems unrelated to deprecation of classic extensions to make way for WebExtensions. So I find that saying:

can be misleading. Regular extensions will be disabled because of WebExtensions, not because of e10s. So as long as they are built with electrolysis in mind, they should keep working for as long as the SDK works as well.

Relative to e10s all extensions stand in the same light, and obviously Mozilla will keep the SDK working with e10s because that’s the only framework they currently maintain (except for WebExtensions). :smile:

BTW I don’t think they can/would deprecate regular extensions (non-XUL-based) and keep SDK add-ons, since SDK add-ons are just a pre-built bootstrap.js that loads scripts in a special environment (that’s my understanding of the SDK at least, am I wrong?). Even if this is actually possible, I really don’t see how it would make sense at all.

Personally, I agree. If it’s already working in a bootstrap.js environment, then it might be easier to just switch a few things to messages than to switch the whole framework to an SDK-based one. I think it’s really your call, to decide what’s better worth your time. :smile:

#12

Actually, regular extensions will be disabled because of XUL deprecation - with the Add-on SDK (as long as it doesn’t touch XUL) and WebExtensions being the two proposed alternatives that will survive XUL deprecation. I never said that supporting e10s in classic or bootstrapped extensions wasn’t possible, but right now one has to plan beyond e10s…

Yes, SDK add-ons are currently a special case of bootstrapped extensions - but they don’t have to be, and it could be that some future extension loading mechanism will go directly for package.json, completely ignoring bootstrap.js (that one is already minimal boilerplate code anyway). That’s how I would do it at least.