User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0 Build ID: 20161208153507 Steps to reproduce: Firefox manages the LocalStorage (https://developer.mozilla.org/en-US/docs/Web/API/Storage/LocalStorage) of various websites. It would be helpful to be able to access these storages from within a WebExtension. I am envisioning an API similar to the existing cookies api: it would allow to get a list of all existing LocalStorage, create a new LocalStorage for any website, edit any LocalStorage, delete any LocalStorage. Maybe also reacting to events when LocalStorages get created, deleted, changed. This would be useful for: An addon that protects the user's privacy by automatically deleting cookies and LocalStorage of a website when the user closes its tab. Such an addon already exists but it is not a WebExtension and I was looking to re-implement it as one. In general extracting any information that websites save in LocalStorage. For example I know some websites that save some user configuration in LocalStorage. An addon could then allow the user to export their configuration even if the website does not have this feature. There is currently no way to do any of this. A partial work around is using content scripts but this will only work for websites that are currently open and not other LocalStorage. I have tried to create an experiment which provides the API described but I do not believe it to be possible with just java script as the needed functions are not exposed to even legacy / non-webextension browser addons. It nearly works with the functions in the nsIDOMStorageManager interface but there is no way to enumerate all existing LocalStorage, only to query LocalStorages which we know the owner of already. Digging around in the c++ code it seems possible to add such a function to that interface without too much work for someone experienced with the Firefox source code which I am sadly not yet. Maybe I will manage in the future. Since this seems implemented in the same way, the same API could also allow access to the SessionStorage. On the mailing list the question was posed if this API should also allow access to other WebExtension's LocalStorage. My opinion is that this should be managed with permissions like it is already done in the cookies api with the host permission. Additionally to just hosts a permission would also control access to other WebExtensions. The whole discussion from the mailing list is readable at https://mail.mozilla.org/pipermail/dev-addons/2017-January/thread.html in the thread "Missing APIs to interact with other websites' LocalStorage".

I dont believe I can edit the first post so apologies if I reply here too often. Relevant c++ classes seem to be: https://dxr.mozilla.org/mozilla-central/source/dom/storage/StorageManager.h https://dxr.mozilla.org/mozilla-central/source/dom/storage/StorageCache.h https://dxr.mozilla.org/mozilla-central/source/dom/storage/Storage.h

The existing cookie + LocalStorage deleter addon is called self descructing cookies. From what I could gather from its source code it parses the webappsstore.sqlite file on disk in which LocalStorages are saved. This is not an official api usage or very future proof.

Existing Storage events: https://developer.mozilla.org/en-US/docs/Web/API/StorageEvent

Could this be done by extending the existing the browswingData api (eg adding a new "origin" option)?

(In reply to Andrew Swan [:aswan] from comment #4) > Could this be done by extending the existing the browswingData api (eg > adding a new "origin" option)? Sorry, I read too fast, that obviously wouldn't cover reading or editing as suggested in the original comment.

I think there might be some argument for implementing this as a devtools API, but I think we should avoid it as a general purpose API. The use cases for clearing and possibly enumerating sites with storage data should be handled by the browsingData API. Accessing it and manipulating it should be possible from content scripts. I don't think the complexity and overhead of this kind of API would be worthwhile for the little it adds beyond what's already available.

(In reply to Kris Maglione [:kmag] from comment #6) As I mentioned in the first post it is not possible to use content scripts in general. As far as I know you cannot run a content script for a website that is not currently opened in any tab even though it might have saved data in the LocalStorage nonetheless. Googling "browsingData API" shows this page https://developer.chrome.com/extensions/browsingData which does not include any method to enumerate or selectively delete LocalStorage. The only operation available is deleting ALL LocalStorage. Of course this doesnt mean the api might not be more extensive in Firefox. While selective deletion would be enough for my initial use case I dont understand why you suggest the API would only add little. From my perspective websites can use the LocalStorage alot like they can use cookies for which an extensive api is available. Also, could you elaborate what you mean with complexity and overhead? Im curious because it didnt look like either of those when I skimmed over the code but admittedly I do not understand it that well. I definitely agree that the devtools should have access to it as I was very suprised to find out that there really is no way at all to list all LocalStorage in them.

(In reply to vakevk+mozilla from comment #7) > As I mentioned in the first post it is not possible to use content scripts > in general. As far as I know you cannot run a content script for a website > that is not currently opened in any tab even though it might have saved data > in the LocalStorage nonetheless. That's true, but I'm not convinced there's anything significant to gain by manipulating site local storage when a site isn't loaded. > Googling "browsingData API" shows this page > https://developer.chrome.com/extensions/browsingData which does not include > any method to enumerate or selectively delete LocalStorage. The only > operation available is deleting ALL LocalStorage. Of course this doesnt mean > the api might not be more extensive in Firefox. We can easily extend that API to delete things on a site-specific basis. The backend implementation for this already exists. > While selective deletion would be enough for my initial use case I dont > understand why you suggest the API would only add little. From my > perspective websites can use the LocalStorage alot like they can use cookies > for which an extensive api is available. The cookie API exists because cookies are tied to network requests, not web APIs, and aren't fully accessible any other way. That's not the case for localStorage. > Also, could you elaborate what you mean with complexity and overhead? Im > curious because it didnt look like either of those when I skimmed over the > code but admittedly I do not understand it that well. When you skimmed over which code?

Apologies for the late reply. (In reply to Kris Maglione [:kmag] from comment #8) > (In reply to vakevk+mozilla from comment #7) > > The cookie API exists because cookies are tied to network requests, not web > APIs, and aren't fully accessible any other way. That's not the case for > localStorage. As we established LocalStorage also isnt FULLY accessible in any other way. > When you skimmed over which code? (In reply to vakevk+mozilla from comment #1) > Relevant c++ classes seem to be: > https://dxr.mozilla.org/mozilla-central/source/dom/storage/StorageManager.h > https://dxr.mozilla.org/mozilla-central/source/dom/storage/StorageCache.h > https://dxr.mozilla.org/mozilla-central/source/dom/storage/Storage.h

To be discussed at the January 24 WebExtensions Triage mtg. Agenda: https://docs.google.com/document/d/1add-6FL8mzksvzbyB83HUmEkVmKERd-nt740AYr-4PE/edit#

I came across this bug when looking at https://bugzilla.mozilla.org/show_bug.cgi?id=1340511. According to the notes from the WebExtensions triage meeting, it was decided that this was a WONTFIX, but this bug has not been updated to reflect that (neither the status nor the whiteboard). I am going to update it accordingly.

Renaming, because removing is possible.