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.