Implement IDBFactory.databases() to enumerate IndexedDB databases
Categories
(Core :: Storage: IndexedDB, enhancement, P2)
Tracking
()
People
(Reporter: daleharvey, Assigned: janv)
References
(Blocks 2 open bugs)
Details
(Keywords: dev-doc-complete, parity-chrome, parity-safari, Whiteboard: DWS_NEXT, [wptsync upstream])
Attachments
(13 files, 3 obsolete files)
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
Updated•7 years ago
|
Comment 1•6 years ago
|
||
Comment 2•6 years ago
|
||
Updated•6 years ago
|
Could we get indexedDB.databases() implemented please?
On Firefox it's not possible to remove indexedDB databases by domain. The reason is the lack of indexedDB.databases() support and chrome.browsingData.remove() doesn't support "hostnames" parameter for indexedDB (it only works for cookies and localStorage). So on Firefox WebExtensions can only remove ALL indexedDB databases for all websites or none.
The implication is that privacy related WebExtensions are seriously handicapped on Firefox compared to Chrome and Firefox is supposed to be the go-to-browser for people who care about privacy.
Chrome supports indexedDB.databases();
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Updated•5 years ago
|
Comment 4•5 years ago
|
||
Comment 5•5 years ago
|
||
Depends on D54141
Comment 6•5 years ago
|
||
Depends on D54142
Updated•5 years ago
|
Comment 10•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Updated•5 years ago
|
Comment 12•4 years ago
|
||
The leave-open keyword is there and there is no activity for 6 months.
:jstutte, maybe it's time to close this bug?
Comment 13•4 years ago
|
||
(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #12)
The leave-open keyword is there and there is no activity for 6 months.
:jstutte, maybe it's time to close this bug?
Simon?
Comment 15•4 years ago
|
||
The attached patches only provide a stub for the IDBFactory.databases
method right now, returning a rejected promise. They work as such, but landing them might confuse feature-detection code. Further work was halted as it turned out that we can't currently query the set of IndexedDB database for an origin from the quota manager in the parent process. Once the quota manager provides this capability, we can implement a an operation on PBackgroundIDBFactory
adding another variant to FactoryRequestParams
, and call that from the child process.
At the moment, the Storage view in DevTools makes up for this missing functionality by reading all the databases in the profile, which could of course break if the storage format changes.
It would be great to replace this once we have a standard way to list databases such as this API.
Comment hidden (advocacy) |
Assignee | ||
Comment 18•3 years ago
|
||
Quota manager is also used for centralized storage management (for example, the unified directory structure on disk), so it's not only about quotas. However, we might implement a workaround which doesn't depend on new quota manager features.
Updated•3 years ago
|
Comment 19•2 years ago
|
||
I was directed here from https://github.com/facebook/sapling/issues/148 because https://reviewstack.dev does not work in Firefox right now because this API is not supported.
From my perspective, I consider this a security issue because not being able to enumerate the databases means that a website has no API it can use to ensure it has removed all of a user's data when they run a "Logout" action of sorts within a web application.
It also prevents a website from removing all IndexedDB data when a user logs in to ensure they start from a clean state.
Comment 20•2 years ago
|
||
Note that the Clear-Site-Data header exists and when used with the "storage" key will comprehensively clear storage API data for the origin and should be preferred if the high level goal is to remove all of a user's data for an origin. This is the most reliable and comprehensive mechanism available. In the future, https://github.com/WICG/storage-buckets should allow more granular but still comprehensive clearing on a per-bucket basis as well.
Comment 21•2 years ago
|
||
(In reply to bolinfest from comment #19)
I was directed here from https://github.com/facebook/sapling/issues/148 because https://reviewstack.dev does not work in Firefox right now because this API is not supported.
From my perspective, I consider this a security issue because not being able to enumerate the databases means that a website has no API it can use to ensure it has removed all of a user's data when they run a "Logout" action of sorts within a web application.
It also prevents a website from removing all IndexedDB data when a user logs in to ensure they start from a clean state.
Surely a website knows the set of names it may or may not have created ... so can delete all whether they exist or not.
(Unless someone is naming their DBs in a non-deterministic way, which seems unlikely and unwise)
Comment 22•2 years ago
|
||
Surely a website knows the set of names it may or may not have created ... so can delete all whether they exist or not.
For a large complex application, this might be true in theory, but in practice keeping track of all databases and making sure they are all cleaned up on logout might not be very practical.
Comment 23•1 year ago
|
||
Came across this now, as I run tests on my company's webtools in various browsers and recently upgraded my code to remove all indexedDB databases to reset state. Why does Firefox lag behind every other browser in this regard?
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Comment 24•1 year ago
|
||
Assignee | ||
Comment 25•1 year ago
|
||
Depends on D188689
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Updated•1 year ago
|
Updated•1 year ago
|
Assignee | ||
Comment 26•1 year ago
|
||
Depends on D54141
Assignee | ||
Comment 27•1 year ago
|
||
Depends on D188975
Assignee | ||
Comment 28•1 year ago
|
||
EnsureBackgroundActor will be also called from IDBFactory::Databases.
Depends on D188979
Assignee | ||
Comment 29•1 year ago
|
||
GetPersistenceType will be also called from IDBFactory::Databases.
Depends on D190017
Assignee | ||
Comment 30•1 year ago
|
||
Depends on D190018
Assignee | ||
Comment 31•1 year ago
|
||
Depends on D190049
Assignee | ||
Comment 32•1 year ago
|
||
Depends on D190052
Assignee | ||
Comment 33•1 year ago
|
||
Depends on D190053
Assignee | ||
Comment 34•1 year ago
|
||
(In reply to y_broderick from comment #23)
Came across this now, as I run tests on my company's webtools in various browsers and recently upgraded my code to remove all indexedDB databases to reset state. Why does Firefox lag behind every other browser in this regard?
If everything goes well, this bug will be fixed in FF 120.
Comment 35•1 year ago
|
||
(In reply to Jan Varga [:janv] from comment #34)
(In reply to y_broderick from comment #23)
Came across this now, as I run tests on my company's webtools in various browsers and recently upgraded my code to remove all indexedDB databases to reset state. Why does Firefox lag behind every other browser in this regard?
If everything goes well, this bug will be fixed in FF 120.
Thanks, much appreciated :)
Assignee | ||
Comment 36•1 year ago
|
||
Depends on D190052
Assignee | ||
Comment 37•1 year ago
|
||
Depends on D190053
Assignee | ||
Comment 38•1 year ago
|
||
Depends on D190053
Assignee | ||
Updated•1 year ago
|
Updated•10 months ago
|
Comment 39•9 months ago
|
||
Comment 40•9 months ago
•
|
||
Backed out for causing xpcshell failures on test_Store.js
- Backout link
- Push with failures
- Failure line:
TEST-UNEXPECTED-FAIL | browser/components/newtab/test/xpcshell/test_Store.js | xpcshell return code: -11
Also there were perma failures on this
Could you please take a look?
Thank you!
Assignee | ||
Updated•9 months ago
|
Comment 41•9 months ago
•
|
||
Please also check this wpt failures
Assignee | ||
Comment 42•9 months ago
|
||
I updated some patches and pushed it to try again, I also triggered extra tests which failed on autoland:
https://treeherder.mozilla.org/jobs?repo=try&revision=f0779f9faeba7a2cf12b999038ebe98bbf66a6bd
https://treeherder.mozilla.org/jobs?repo=try&revision=4f69bc848c9219b8decd5b89943da5fcfc3188e7
https://treeherder.mozilla.org/jobs?repo=try&revision=e30a9c222dc3855d1f8444602cf2ddcfa3df0ede
So far it looks good, going to re-land soon.
Comment 43•9 months ago
|
||
Assignee | ||
Updated•9 months ago
|
Comment 44•9 months ago
|
||
Backed out for causing wpt failures in idb-explicit-commit.any.html
- Backout link
- Push with failures
- Failure Log
- Failure line: TEST-UNEXPECTED-FAIL | /IndexedDB/idb-explicit-commit.any.html | Transactions that handle all errors properly should behave as expected when an explicit commit is called in an onerror handler. - assert_equals: Expected complete event, but got abort event instead expected "complete" but got "abort"
Assignee | ||
Comment 45•9 months ago
|
||
I re-triggered the test on autoland just to be sure it's not bug 1799374 or something like that.
How is it possible that re-triggered tests are all green ?
https://treeherder.mozilla.org/jobs?repo=autoland&revision=f842e559422478115a52b4f74444a3be2cacbcbb
Assignee | ||
Comment 46•9 months ago
|
||
I triggered the test also on the try push I did just before landing on autoland:
https://treeherder.mozilla.org/jobs?repo=try&revision=e30a9c222dc3855d1f8444602cf2ddcfa3df0ede&selectedTaskRun=FeHTaKWiQ4SthlZHcBjoxg.0
It's still running ...
Comment 47•9 months ago
•
|
||
Because you did not retrigger it in a good way, you retriggered the wpt17 jobs, where "/IndexedDB/idb-explicit-commit.any.html" did not run. we have backfills in place: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&searchStr=linux%2C18.04%2Cx64%2Cwebrender%2Ctsan%2Copt%2Cweb%2Cplatform%2Ctests%2Ctest-linux1804-64-tsan-qr%2Fopt-web-platform-tests%2Cwpt17&fromchange=33e78b58e39fe602a8fcc6ab12a2f2bc513b66e3&tochange=adf17fc47c84c0fa237aecff550ba42344a5c629&selectedTaskRun=ZcxsCEcoS2C72O9m-QOjIQ.0 and the backfills stop at your push. If you see a wpt17 green that does not mean it ran "/IndexedDB/idb-explicit-commit.any.html" test, they can switch chunks. You can check the log for the green jobs and search for "/IndexedDB/idb-explicit-commit.any.html" to see if the test ran.
Comment 48•9 months ago
•
|
||
Also you can see a bunch of retriggers here: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception%2Cusercancel&revision=adf17fc47c84c0fa237aecff550ba42344a5c629&searchStr=wpt&selectedTaskRun=a04poKjrRr28edDtnAAnjg.0 and also on other platforms.
Assignee | ||
Comment 49•9 months ago
|
||
I triggered all the chunks, let's see ...
Assignee | ||
Comment 50•9 months ago
|
||
I explicitly triggered all wpt tests for all shippable builds on the try push prior to landing, and it was all green.
Let's see if it's really only tsan.
Comment 51•9 months ago
|
||
It's not only tsan, it shows on multiple platforms: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception%2Cusercancel&revision=adf17fc47c84c0fa237aecff550ba42344a5c629&searchStr=wpt&selectedTaskRun=Tul9xZPpSz-9mq4AagsZFQ.0 and also you have multiple 12 revisions in autoland and only 3 on try, couldn't this be caused by the revisions that are not in you try push?
Assignee | ||
Comment 52•9 months ago
•
|
||
(In reply to Cristian Tuns from comment #51)
It's not only tsan, it shows on multiple platforms: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception%2Cusercancel&revision=adf17fc47c84c0fa237aecff550ba42344a5c629&searchStr=wpt&selectedTaskRun=Tul9xZPpSz-9mq4AagsZFQ.0 and also you have multiple 12 revisions in autoland and only 3 on try, couldn't this be caused by the revisions that are not in you try push?
The other change sets/patches are there, they are just not shown because I did two other try pushes prior to that:
https://treeherder.mozilla.org/jobs?repo=try&revision=f0779f9faeba7a2cf12b999038ebe98bbf66a6bd
https://treeherder.mozilla.org/jobs?repo=try&revision=4f69bc848c9219b8decd5b89943da5fcfc3188e7
https://treeherder.mozilla.org/jobs?repo=try&revision=e30a9c222dc3855d1f8444602cf2ddcfa3df0ede
Assignee | ||
Comment 53•9 months ago
|
||
Assignee | ||
Comment 54•9 months ago
|
||
I'll do more testing on try, but it looks like it's a variation of existing intermittent bug 1799374
https://treeherder.mozilla.org/jobs?repo=try&revision=8ee684b669a23bd621f6427adf73d66cc3532a7c&selectedTaskRun=ABRD3oXIQFe076OpYK2q8g.0
https://treeherder.mozilla.org/jobs?repo=try&revision=8ee684b669a23bd621f6427adf73d66cc3532a7c&selectedTaskRun=XZ1utCTiT4a8kGdOrenebw.0
I still wonder why triggering of all wpt chunks didn't run IndexedDB/idb-explicit-commit.any.html
This time I rather used: mach try fuzzy testing/web-platform/tests/IndexedDB
Comment 55•9 months ago
•
|
||
I backfilled it multiple times to make sure I backed out the right patch and here's the link: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&searchStr=linux%2C18.04%2Cx64%2Cwebrender%2Ctsan%2Copt%2Cweb%2Cplatform%2Ctests%2Ctest-linux1804-64-tsan-qr%2Fopt-web-platform-tests%2Cwpt17&fromchange=33e78b58e39fe602a8fcc6ab12a2f2bc513b66e3&tochange=4132892d754dddce6198ca04a7119f25a8ebfa9e&selectedTaskRun=MYk0kTKMRRqQHtSjiVzigA.0
Assignee | ||
Comment 56•9 months ago
|
||
Ok, thanks.
The frequency of the intermittent failure is higher and it's especially bad on tsan and some other builds.
https://treeherder.mozilla.org/jobs?repo=try&revision=8ee684b669a23bd621f6427adf73d66cc3532a7c
Assignee | ||
Comment 57•9 months ago
|
||
Yeah, as I commented in bug 1799374, the frequency of the intermittent failure is affected by multiple factors. Patches for this bug affect it too.
We could just temporarily disable the test and land the patches, but now when I know what the problem is, I think it's better to fix the long standing intermittent failure first.
Updated•8 months ago
|
Comment 58•8 months ago
|
||
Comment 59•8 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/2bf7b30a3031
https://hg.mozilla.org/mozilla-central/rev/44b6e445fae2
https://hg.mozilla.org/mozilla-central/rev/752a77c2aeb7
https://hg.mozilla.org/mozilla-central/rev/24996a9ac5b9
https://hg.mozilla.org/mozilla-central/rev/e343ab147db6
https://hg.mozilla.org/mozilla-central/rev/3593380ad495
https://hg.mozilla.org/mozilla-central/rev/2239c6fa5b86
https://hg.mozilla.org/mozilla-central/rev/e2c42f46453a
https://hg.mozilla.org/mozilla-central/rev/dd3f65f53626
https://hg.mozilla.org/mozilla-central/rev/91aad7241b01
https://hg.mozilla.org/mozilla-central/rev/bcdddd575816
https://hg.mozilla.org/mozilla-central/rev/0ead0c93d2e3
Comment 61•8 months ago
|
||
:janv could you consider nominating this for a release note? (Process info)
We could include it in the nightly release notes.
Assignee | ||
Comment 62•8 months ago
|
||
Yeah, worth a short note in release notes.
Assignee | ||
Comment 63•7 months ago
|
||
Release Note Request (optional, but appreciated)
[Why is this notable]: IDBFactory.databases() is one of the major API methods and FF was the last browser not supporting it.
[Affects Firefox for Android]: Yes
[Suggested wording]: Web Platform, Firefox now supports IDBFactory.databases (for enumeration of IndexedDB databases).
[Links (documentation, blog post, etc)]:
https://developer.mozilla.org/en-US/docs/Web/API/IDBFactory/databases
https://www.w3.org/TR/IndexedDB/#dom-idbfactory-databases
Comment 64•7 months ago
|
||
Thanks, added to the Fx126 nightly release notes, please allow 30 minutes for the site to update.
Keeping the relnote-firefox flag as ? to keep it on the radar for inclusion in the final Fx126 release notes
Comment 65•7 months ago
|
||
FF126 MDN docs work for this can be tracked in https://github.com/mdn/content/issues/33084.
Updated•7 months ago
|
Updated•7 months ago
|
Description
•