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.
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.
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
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?
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.
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.
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?
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
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?
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.
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!
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.
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:
Done and per request of Luca Grego, I attached my corrupt state.