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…
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.
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.
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
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.
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.