Closed Bug 1427234 Opened 8 years ago Closed 2 years ago

"Site Data" website list doesn't consider localStorage

Categories

(Firefox :: Settings UI, enhancement, P4)

enhancement

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: kalle, Unassigned)

References

Details

(Whiteboard: [storage-v2])

Preferences > Privacy > "Site Data" only lists websites with existing IndexedDB data. It doesn't seem to be possible to retrieve a list of sites that have stored only Web Storage data. Neither is it possible to delete such Web Storage data. (However, if a site has stored IndexedDB data, invoking the delete action clears any Web Storage data as well.)
This will probably resolve itself with bug 1286798 (so there's nothing really actionable here at the time) but it's probably still wise to keep a bug around for the problem.
Status: UNCONFIRMED → NEW
Depends on: 1286798
Ever confirmed: true
Summary: "Site Data" website list doesn't consider Web Storage data → "Site Data" website list doesn't consider localStorage
Whiteboard: [storage-v2][triage]
Priority: -- → P4
Whiteboard: [storage-v2][triage] → [storage-v2]
Johann, I had some time to kill. Apologies if this gets slightly long. Just making sure its crystal clear what i did. FF59.0.1 vanilla profile - I have only 1st party cookies enabled and disk cache disabled, but these shouldn't matter. - I also have activity tab disabled, and new tabs to open a blank (I do not want any inadvertent persistent data) Clear all persistent data (ctrl-shift-del, time range everything, check all options) - check there is no persistent local data --- no cookies in chrome://browser/content/preferences/cookies.xul --- no IDB - profile/storage/default (no http* directories) --- no disk cache, no appCache - about:cache --- no localStorage - profile\webappsstore.sqlite (webappstore2 table is empty) --- not entirely sure how to check Service Workers cache - Site Data should show 0 bytes, settings should be empty - Now I know ctrl-shift-del etc clears all data Load https://github.com/ - Stay on the page and hit Shift-F9 to open the Storage Inspector. You will have some cookie + localStorage entries, but no IDB (as per comment 0) - Reload about:preferences#privacy and check Site Data, it should now say 64 KB. - Look in Settings and you will see github - Click Clear All Data - it worked (I checked webappsstore.sqlite) Make sure Storage Inspector is closed, clear everything (ctrl-shift-del) and reload github - do NOT use the Storage Inspector - Reload about:preferences#privacy and check Site Data, it should still say 0 KB (but we know it has data I even checked the sqlite again) - Click Clear All Data - it worked (I checked webappsstore.sqlite is now empty) Conclusion (FF59.0.1) ========== So the problem is cosmetic only, localStorage with no IDB does get cleared regardless of what Site Data displays, and Site Data just needs a trigger (whatever opening Storage Inspector did) to repopulate its information
Hi Simon, thanks for verifying that. Note that there's bug 1401542 for storage inspector not updating storage correctly at times. The site data manager currently indeed needs a refresh before updating data, something that could get resolved as a follow-up to bug 1252998...

I would expect that "clear site data" also clears localStorage. In my test, it seems to clear localStorage when you clear other site data, but then the site is free to set localStorage again and it will no longer show up in the list of sites that store data on your system, nor will 'clear cookies and site data' show up anymore if you click the lock icon in the address bar for that site. But then it's still available if you click through to the security tab in the site info dialog window.

It's quite inconsistent in its current state.

(In reply to Luc from comment #4)

In my test ...

Is dom.storage.next_gen set to `true? If not, flip it to true, restart (not sure if a restart is required), and see if you can still reproduce

(In reply to Simon Mainey from comment #5)

Is dom.storage.next_gen set to `true? If not, flip it to true, restart (not sure if a restart is required), and see if you can still reproduce

That fixes the inconsistencies! Is that planned to become the default at some point? Ducking that setting, it seems to have caused issues in the past, not sure what the latest plans for it are or if a redesign under a different name is in the works.

(In reply to Luc from comment #6)

(In reply to Simon Mainey from comment #5)

dom.storage.next_gen

That fixes the inconsistencies! Is that planned to become the default at some point?

that's bug 1599979

Severity: normal → S3
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.