XPCOM with Multiprocess Firefox

Add-ons Development
#1

Hello,

With FF 49 my extensions started to behave differently. I think the reasons is the Multiprocess behavior.
Here is some docs that I have read:
https://developer.mozilla.org/en-US/Add-ons/SDK/Guides/Multiprocess_Firefox_and_the_SDK
<< High-level APIs will just work in multiprocess Firefox. If they don’t, it’s an SDK bug.
Low-level APIs might not work. If you’re using low-level APIs, review your use of them, test, and potentially refactor. >>
https://developer.mozilla.org/en-US/Add-ons/Working_with_multiprocess_Firefox#Checking_whether_you’re_affected

The problem I encounter is that I don’t think there are any High Level API or WebExtension API equivalent of what my extension is currently doing.

The most critical part is:
My extension is dynamically creating a search engine, using the following XPCOM APIs
nsIDOMSerializer
nsIDOMParser
nsIFileOutputStream
nsILocalFile

Basically edit a XML local resource, and move it into the ProfD folder of Firefox.

Anyone has suggestions about how to handle those kind of use cases? High Levels APIs don’t allow to read a local file and edit it…

Thanks

#2

DOMParser and DOMSerializer should be available in a normal DOM environment, so for example everywhere in webextensions or a page-worker in the SDK. The file stuff can currently not be achieved without low-level SDK modules but I believe a WebExtensions API is in development.

#3

If my memory serves, nsIDOMParser can be replaced with DOMParser and nsIDOMSerializer with XMLSerializer.

Now, if your code is executed in a content process, it doesn’t have access to local files. You’ll need to execute the code that has access to local files from the parent process.

Also, instead of nsIFileOutputStream and nsILocalFile, I strongly recommend using OS.File, which is both simpler and faster.

#4

But OS.File relies on a XPCOM module…
// To read content from file
const {TextDecoder, OS} = Cu.import(“resource://gre/modules/osfile.jsm”, {});

Mozilla says:
Legacy XUL or XPCOM add-ons
We expect to remove XUL and XPCOM from Firefox by the end of 2017.
in this page https://developer.mozilla.org/en-US/Add-ons/Working_with_multiprocess_Firefox#Checking_whether_you're_affected

Basically I am pretty sure that I can replace some of the APIs, but not all, and that’s the problem.

For instance the full list of APIs that our extension is using is:

Low Level APIs:
sdk/preferences/service
sdk/io/file
sdk/fs/path
sdk/places/history
sdk/ui/button/toggle
chrome

XPCOM APIs (which are dependant on the Low Level “chrome” API)
require(‘chrome’):
Services.jsm
NetUtil.jsm
FileUtils.jsm
NewTabURL.jsm
nsIDOMParser
nsIDOMSerializer
nsIPromptService
nsIFileOutputStream
nsIProperties
nsILocalFile
nsISearchEngine

High Level APIs:
sdk/simple-prefs
sdk/self
sdk/simple-storage
sdk/request
sdk/page-mod
sdk/notifications
sdk/l110n
sdk/system
sdk/tabs
sdk/timers
sdk/panel

#5

The statement is accurate, however until a relevant replacement API for WebExtensions is implemented you will have to rely on the XPCOM approach.

P.S.: you can use require("some.jsm") instead of Cu.import("some.jsm", {}).

#6

Is there a possibility that there is never a WebExtensions API replacement for an XPCOM API feature?

I can’t find anywheres saying that the WebExtensions API capabilities will be equivalent to what is currently available. If WebExtensions APIs are closer to what Chrome provides, I don’t think there will be any way to save a resource in the profD folder for example… I guess it’s wait&see

#7

Certainly. Currently any type of Firefox extension can do absolutely everything. Which is one of the reasons why Mozilla reviews every submitted extension by hand.

I can’t find anywheres saying that the WebExtensions API capabilities will be equivalent to what is currently available.

If they would, they would be pointless, wouldn’t they? However, Mozilla thrives to do more than Chrome does. Implementing the common subset with Chrome, Opera and Edge was just a first step.
I’d expect that (probably except for the file system and direct access to the config) everything you mentioned above will be available at some point.

So, let’s

wait&see

(or actively push the development of the APIs you need by suggesting https://wiki.mozilla.org/WebExtensions/Experiments.

#8

Thanks everyone, good feedback!

#9

OS.File does not rely on any XPCOM.

You do not have to use TextDecoder on TextEncoder if you want to simply use OS.File.writeAtomic or OS.File.read, the options argument accepts an object with key encoding which you can set to "utf-8".

The great thing about OS.File is that you can use it from ChromeWorker’s as well.