Open Bug 1488733 Opened 6 years ago Updated 2 years ago

Opening Storage Inspector creates quota storage entry for site

Categories

(DevTools :: Storage Inspector, defect, P3)

61 Branch
defect

Tracking

(Not tracked)

People

(Reporter: ph, Unassigned)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180807170231

Steps to reproduce:

1. Open example.com (any webpage that does not ordinarily use localStorage; I tested with hacks.mozilla.org, among others).
2. Open about:preferences#privacy in a separate tab. Under Cookies and Site Data, click on Manage Data and see that there is no entry for example.com in the Storage column.
3. In the example.com tab, open the Storage Inspector.
4. Refresh the Preferences tab and click on Manage Data again. There is now an entry for example.com in the Storage column with a value of 64.0 KB.
5. Close the example.com tab.
6. Check the History menu to see that example.com is at the top of both the main History list and the Recently Closed Tabs list.
7. Back in Preferences, select the example.com entry, click Remove Selected, click Save Changes, and click Remove.
8. Check the History menu again.


Actual results:

example.com should be at the top of both the main History list and the Recently Closed Tabs list.


Expected results:

example.com is still at the top of the main History list but gone from the Recently Closed Tabs list.

Note: This bug only appears for me if I delete the site's localStorage *after* the tab is closed. If I delete the localStorage first and then close the tab, the site is not removed from Recently Closed Tabs.
Component: Untriaged → Preferences
Flags: needinfo?(jhofmann)
Thank you for your report, but please don't file two issues in the same bug, create one bug for each, instead (because separate people will implement separate fixes for them that we can't just stuff in one bug).

We are discussing the Recently Closed Tab list in bug 1483440, so I think it's fine to just focus this bug on the DevTools Storage Inspector issue.

I can reproduce by going to example.com, opening the storage inspector and calling Services.qms.getUsageForPrincipal(gBrowser.contentPrincipal, console.log) in the browser toolbox. So it's very unlikely this is an issue with the site data manager.
Status: UNCONFIRMED → NEW
Component: Preferences → Storage Inspector
Ever confirmed: true
Flags: needinfo?(jhofmann)
Product: Firefox → DevTools
See Also: → 1483440
Summary: enabling Storage Inspector creates localStorage DB for site; deleting DB deletes site's Recently Closed Tabs entry → Opening Storage Inspector creates quota storage entry for site
Thanks for sorting this out, Johann. I didn't know whether the creation of the quota storage entry was intended behavior or not.
Has STR: --- → yes
OS: Unspecified → All
Priority: -- → P3
Hardware: Unspecified → All

Could this be because we create an internal fx-devtools indexedDB when we open devtools?

Here is a slightly different test snippet that you can run in the browser console:

const origin = Services.scriptSecurityManager.createContentPrincipalFromOrigin("http://example.com");
Services.qms.getUsageForPrincipal(origin, r => console.log("usage", r.result.usage));

It help simplifying comment 0's STR.

I can see that opening the inspector doesn't trigger this. But I was able to reproduce when opening the storage panel.
Services.qms goes over folders and files in the profile folder:
https://searchfox.org/mozilla-central/rev/e75e8e5b980ef18f4596a783fbc8a36621de7d1e/dom/quota/ActorsParent.cpp#9016-9094
This is the component used by about:preferences to show usage numbers.

Locally, I can see that various folders and files are created, only when opening DevTools.

  • http+++example.com/.metadata-v2 (binary file)
  • http+++example.com/cache/caches.sqlite
  • http+++example.com/cache/.padding (binary file)
  • http+++example.com/cache/morgue (empty folder)

Looking into caches.sqlite, the database looks empty:

$ sqlite3 caches.sqlite 
SQLite version 3.22.0 2018-01-22 18:45:57
Enter ".help" for usage hints.
sqlite> .dump
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE caches (id INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT );
CREATE TABLE security_info (id INTEGER NOT NULL PRIMARY KEY, hash BLOB NOT NULL, data BLOB NOT NULL, refcount INTEGER NOT NULL);
CREATE TABLE entries (id INTEGER NOT NULL PRIMARY KEY, request_method TEXT NOT NULL, request_url_no_query TEXT NOT NULL, request_url_no_query_hash BLOB NOT NULL, request_url_query TEXT NOT NULL, request_url_query_hash BLOB NOT NULL, request_referrer TEXT NOT NULL, request_headers_guard INTEGER NOT NULL, request_mode INTEGER NOT NULL, request_credentials INTEGER NOT NULL, request_contentpolicytype INTEGER NOT NULL, request_cache INTEGER NOT NULL, request_body_id TEXT NULL, response_type INTEGER NOT NULL, response_status INTEGER NOT NULL, response_status_text TEXT NOT NULL, response_headers_guard INTEGER NOT NULL, response_body_id TEXT NULL, response_security_info_id INTEGER NULL REFERENCES security_info(id), response_principal_info TEXT NOT NULL, cache_id INTEGER NOT NULL REFERENCES caches(id) ON DELETE CASCADE, request_redirect INTEGER NOT NULL, request_referrer_policy INTEGER NOT NULL, request_integrity TEXT NOT NULL, request_url_fragment TEXT NOT NULL, response_padding_size INTEGER NULL );
CREATE TABLE request_headers (name TEXT NOT NULL, value TEXT NOT NULL, entry_id INTEGER NOT NULL REFERENCES entries(id) ON DELETE CASCADE);
CREATE TABLE response_headers (name TEXT NOT NULL, value TEXT NOT NULL, entry_id INTEGER NOT NULL REFERENCES entries(id) ON DELETE CASCADE);
CREATE TABLE response_url_list (url TEXT NOT NULL, entry_id INTEGER NOT NULL REFERENCES entries(id) ON DELETE CASCADE);
CREATE TABLE storage (namespace INTEGER NOT NULL, key BLOB NULL, cache_id INTEGER NOT NULL REFERENCES caches(id), PRIMARY KEY(namespace, key) );
DELETE FROM sqlite_sequence;
INSERT INTO sqlite_sequence VALUES('caches',1);
CREATE INDEX security_info_hash_index ON security_info (hash);
CREATE INDEX entries_request_match_index ON entries (cache_id, request_url_no_query_hash, request_url_query_hash);
CREATE INDEX response_headers_name_index ON response_headers (name);
COMMIT;

So, it looks like DevTools force the creation of many files related to storages, but all of this is empty!
Nonetheless, the two binary files and the empty sqlite database (which isn't completely empty, the tables are defined) is already 64KB.

I agree this can be really confusing, but DevTools isn't creating any unexpected data, it only forces the creation of internal storage files, which empty are doing 64KB.

See Also: → 1401482
Blocks: 1312444
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.