Get storage.StorageArea size and let user decide if sync or local


(Undflybir) #1

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 });
  });
}

(Martin Giger) #2

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.


(Undflybir) #3

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?


(Martin Giger) #4

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.