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.
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.