The docs of storage.StorageArea
say storage.StorageArea.getBytesInUse()
is not supported in Firefox.
Is there a way to get the storage size anyway?
Also, 100KB for storage.sync
doesn’t seem a lot. Therefore I’d like to let the user decide for local or synced storage.
Would it be a good pattern to store the settings synced and for all other data to use checkboxes in the settings for “local” and “synced” and all data to be stored is being stored according to this setting like this:
storeData(toBeStored) {
browser.storage.sync.get().then(storage => {
browser.storage[storage.StorageArea].set({ data: toBeStored });
});
}
I’d make the sync opt-in (or out) a local pref, so the user can have different settings for a specific device.
Edit: to store a lot of data locally it’s recommended to use indexedDB instead, since storage.local
is just serialized to a plaintext file.
1 Like
I’m still uncertain on which storages to use.
browser.storage.sync
is limited to 100KB - is there a way to retrieve the current storage size?
browser.storage.local
: what is the limit here?
indexedDB
: is {storage: "persistent"}
depricated?
With the SDK API simple-storage
used to be cleared on an irregular browser shutdown (crash) - can the same happen with browser.storage.local
or indexedDB
?
Would it make sense to also use navigator.storage.persist()
to make sure the user doesn’t lose his/her data on a Firefox crash?
browser.storage.local
: what is the limit here?
No limit, resp. the user’s disk size, or the max size of files the user’s disk supports.
indexedDB
: is {storage: "persistent"}
depricated?
Yes, use navigator.storage.persist()
instead. You need the unlimitedStorage
permission if you want to call that without the user getting a doorhanger. Also, persisting doesn’t help with dataloss on crashes, as far as I know. Instead it is about vacuuming (as in, making space) policies.
browser.storage.local
is currently file-backed (may move to indexedDB), so it is also prone to having write errors on crashes, not sure about indexedDB there.
1 Like