WebExtension - how to read/write local file

Add-ons Development
#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.

1 Like
#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.

1 Like
#3

Hi,

Iā€™m not sure why Niklas didnā€™t suggest the Storage API:
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/storage

That is what you should use.

Eric

1 Like
#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?

1 Like
#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.

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

1 Like
#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?

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

Eric

1 Like
#9

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?

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

#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!

#12

browser.storage will break upwards compatibility every now and then, and nobody on Firefox-team appears to know why and/or care. You have been warned.

1 Like
#13

Thank you for pointing this out!
Iā€™ve received some bug reports recently that didnā€™t make sense, but now Iā€™m sure this is the case.

Iā€™ve been getting reports with broken IndexedDB engine like twice a week (since 2017) but now when Firefox 66 migrated storage.local into IndexedDB, my add-on will fail to load completely because I donā€™t have any error handling for the storage.local.get!!!

Please, could you mention your case in this bug thread:

#14

Done and per request of Luca Grego, I attached my corrupt state.

1 Like