WebExtension - how to read/write local file

(Kjonca) #1

I want to write some extension which (basically) takes some pages from site, translate them into json and write to file.
I can do it with SDK io/file but it is considered deprecaded.
Is it possible with WebExt?
So far found two words:
nativeApp - workaround with simple helper app
os.file.jsm - but it is not clear for me how to use it to save my data to local file.

(Niklas Gollenstede) #2

Currently, there are two ways to write files:

  • use nativeMessaging to pass the data to a separately installed program on the computer
  • triggering the “Save as” dialog

booth have considerable disadvantages. The former needs the user to install a programm that needs to be updated interdependently of the browser and extension, the latter requires explicit user interaction and may not always work.

(Eric Jung) #3


I’m not sure why Niklas didn’t suggest the Storage API:

That is what you should use.


(Kjonca) #4

But I want to have persisent (ie firefox does not delete these when extension is uninstalled) files, outside the profile. Can storage api do this?

(Eric Jung) #5

But I want to have persisent (ie firefox does not delete these when extension is uninstalled) files, outside the profile. Can storage api do this?

For obvious reasons, no.

(Niklas Gollenstede) #6

The browser.storage is well suited for primitives and small objects of those, accessible in content scripts and with the option to have it synced between multiple browsers of a profile.
For larger collections of structured values/objects and binary data, indexedDB is much faster.

If you need to read or write file system files, the options I mentioned before are the only ones.

(Leif) #7

What are the ‘obvious reasons’ for ‘no’? To me there are obvious reasons that this should be ‘yes’.

A user may want to uninstall a new buggy version of add-on to force installation of an older version without the bug. The add-on may also have a complex set of options. Rather than force the user to re-configure the add-on, it is preferable to provide some mechanism to retain their settings.

This could be automatic in nature, as the old XUL about:config preferences behaved by default, or it could be coded by the add-on to store settings in a file to use as user-defaults later, which would over-ride add-on defaults (again as XUL preferences behaved, which was the intelligent and sane way to handle preferences).

Or this could be implemented as a settings export feature, which would allow the user to specify a file outside of the add-on folder for later import, perhaps on reinstalling this add-on, or installing a forked version, or in the process of setting up a managed setting (if Firefox ever implements managed storage).

There are many valid use cases where the ‘obvious’ answer ‘should be’ yes, but instead, we are left without key features in WebExtensions, and vague and often empty promises that such functionality will be added.

And also, the answer of no is technically incorrect, at least in part, according to the WebExtensions storage.local documentation page.

Also in Firefox, you can prevent the browser from clearing local storage on uninstall by visiting “about:config” and setting the following two browser preferences to true: “keepUuidOnUninstall” and “keepStorageOnUninstall”. This feature is provided to help developers test their add-on. WebExtensions themselves are not able to change these preferences.

This may not be desirable to instruct users to do, though, because there is no granularity of control for a specific add-on. It will affect ALL add-ons which may very well be undesirable. You generally don’t want to always leave cruft laying around by default. But perhaps it also could be handled by native messaging to the browser itself?

(Eric Jung) #8

Sorry for using the word ‘obvious’ since that’s a very relative term. Reading/writing local files opens many attack vectors for malware. That is why it is not permitted. It may be sometime in the future, but won’t be for Firefox 57.



So my extension reads Flash log files into the extension. It also modifies mm.cfg (a config file read by Flash). How will I be able to do either of these now?

(Niklas Gollenstede) #10

Flash is thankfully dying rather quickly by now, so porting may not be worth the effort.

If you do want to port, you will not get around native messaging. I have recently put quite some effort into this cross-platform native messaging helper application, that strives to make things as easy as possible for both developers and users.

(Pierre-Adrien) #11

This is interesting. Honestly, the “IndexedDB” name rings a bell, but I didn’t really have any notion as to what it was useful for. I’ll be looking into it then, it might be really useful to me + better perfs. Thanks for this short explanation!