Understanding extension permission "unlimitedStorage"

Add-ons Development
#1

In this MDN document concerning extension permissions there is a brief note about this permission and persistent storage without requesting user permission.

Would you please tell me where to read on how to make an indexedDB database persistent with or without user permission? Does unlimited apply to indexedDB also or only the storage.local API.

Also, what happens to a persistent database if the user never visits the site again? My main concern is that I was thinking of using this for a local HTML set up and wondered what happens if the user deletes the local HTML file. There would be a database associated with it but no way of ever reaching it again to delete it from where the browser stores it locally.

Thank you.

#2

The persistent IndexedDB part only applies to indexedDBs created in extension pages, so HTML pages contained within your extension.

Persisting a database is done with

though the necessity of calling that from extensions has never been quite clear. You can also figure out your updated quotas with storage manager. I’m pretty sure it does not extend your quota beyond the 2GB available.

#3

Thank you for the information and link.

I’m confused by references to “your site’s storage” under the persist and persisted methods below. Does it apply to the site origin or to an extension only? Thank you.

StorageManager.persist() Secure context

Returns a Promise that resolves to true if the user agent is able to persist your site’s storage.

StorageManager.persisted() Secure context

Returns a Promise that resolves to true if persistence has already been granted for your site’s storage.

#4

Your extension is a “site” in the eyes of web APIs. That means every HTML file included in your extension (that also includes the background page" is a page part of your site.

If you call this API in a contentScript it will apply to the site the content script is attached to and unlimitedStorage has no effect.

#5

Oh, I think I see now. When you refer to HTML files included in your extension, do you mean the pages the extension can act upon or only those HTML files loaded with the manifest package?

I apologize; I’m slow to understand sometimes. If my extension acts upon a local HTML file and the content script added to it requests StorageManager.persist(), will the database of that local page be deleted later than the others when space becomes limited?

And, if so, how can it be deleted if the page is not loaded again?

If I add the following code to a local HTML page and open it without the extension installed, the browser requests permission to have the data persist. From reading the other MDN documentation on the “unlimitedStorage” permission, it appears that the browser will no longer ask for the user’s permission.

I thought my little set up was working great until I thought about what would take place if the database of that local HTML page was persisted and the user subsequently deleted the local HTML file. How can I remove the associated SQLite file from the local disk where the browser stores it?

It appears that I need to figure out how to clean that up or not have that data persist.

Thank you.

if (navigator.storage && navigator.storage.persist)
  navigator.storage.persist().then(function(persistent) {
    if (persistent)
      console.log("Storage will not be cleared except by explicit user action");
    else
      console.log("Storage may be cleared by the UA under storage pressure.");
  });
#6

So, permissions primarily affect scripts running in pages included in your extebsion bundle. Any ither website, local or not can only be interacted with through content scripts. Whatever you do from content scripts is mostly guarded by the normal rules for the website it’s running in.

See this doc guide for more details on what content scripts can do that is outside what the page itself can do.

IndexedDB and all other storage methods websites can use (like cookies) are generally guarded by history/cookie cleaning rules. There are eviction rules for non-persistendlt indexedDBs apart from that. However it is not based around the website (local or not) being reachable.

As extebsion you should avoid storing data in the context of a website unless you’re manipulating the page’s storage to interact with its features.

#7

Thank you. I think I better understand the relation between permissions of the extension and what a content script can do now. However, I’m still not quite understanding how that relates to my question.

Without an extension, a web page, local or not, can request the user’s permission to persist an indexedDB database. At least it appears that way in my little experiments.

I don’t understand how the user can delete that database after electing to let it persist. Furthermore, I don’t understand how, in the scenario of an extension persisting the database for the user, it can later programmatically be deleted without having the page open.

For example, if the extension’s database tracks every persisted database it creates and the URL of it, could it delete that database without having the page open, since it is stored locally by the browser?

If it helps to understand why I’m asking what likely seems a bit odd, I’m using local HTML files because I want to give the user a way to incorporate local resources into the functionality of the extension, and the local HTML file gives me a hook to a relative path through which those resources can be used. The extension cannot load the local resources directly. Furthermore, having a database in each local HTML file gives a modular set up to the tool such that the user can build many of these packages independently and not have an aggregate storage limit of whatever the extension’s indexedDB database may be.

All of that works, but I’m concerned about how to keep that disk space managed as the user builds and deletes their modules, since the OS isn’t going to notify the extension that the user just deleted the local HTML file and that it should be deleted from the browser. The user, of course, could delete the database before deleting the local files; but I don’t want to count on that taking place.

Thank you.

#8

Because there is no automated way to clean up persistent storage is exactly why the user must explicitly consent to it for every origin. I believe deleting the appropriate browsing data for a website will also delete the persistent storage data. You can trigger that API from an extension iirc. I’m not sure how the feature behaves with the file: protocol since files have a very weird origin.

Of course the persistent extension storage is deleted when the extension is uninstalled, thus there is no need to ask the user about allowing persistent databases or such. And no, you also can’t clean up all the databases that you’ve created for other origins when your extension is uninstalled.

#9

Thank you, I’ll give that a try. I can’t see local files in the list of web sites when deleting site data. I don’t think they show up there but the persisted database is deleted if you delete data for all sites in the list.