Chrome indexeddb databases show up in the devtools' storage panel for a webpage
Categories
(DevTools :: Storage Inspector, defect, P1)
Tracking
(firefox-esr78 unaffected, firefox81 unaffected, firefox82 unaffected, firefox83 wontfix, firefox84 fixed)
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox81 | --- | unaffected |
firefox82 | --- | unaffected |
firefox83 | --- | wontfix |
firefox84 | --- | fixed |
People
(Reporter: julienw, Assigned: ladybenko)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files)
STR:
- go on any webpage, for example this page.
- open the devtools' storage panel
- open the Indexed DB item
=> we see entries that are related to Firefox in addition to the entry for the current website.
Julian said this is happening when Remote Debugging + Chrome debugging is enabled.
This seems quite new.
Reporter | ||
Comment 1•4 years ago
|
||
I ran mozregression and found:
pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=37cd0824dd4b3d84fc5a68cfd91150c1af77146a&tochange=3e4fdf53c557132a0cb11b7dc3964e61844e7b31
bug 1625935
Updated•4 years ago
|
Comment 2•4 years ago
|
||
Thanks Julien for the report and regression bug!
I can reproduce on my machine easily (Win10, Nightly)
Alex, do you know what caused the issue in David's patch?
Honza
Updated•4 years ago
|
Comment 3•4 years ago
|
||
Set release status flags based on info from the regressing bug 1625935
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 4•4 years ago
|
||
In https://phabricator.services.mozilla.com/D91122#C3084925OL296 we transferred the filtering of indexedDB dbs to a transformer, but it was not being applied since the hosts
getter was still used by the client. Since we discussed this filtering should be done in the server, this patch moves the filtering to the storage actor instead.
Updated•4 years ago
|
Comment 6•4 years ago
|
||
Backed out for causing leaks
backout: https://treeherder.mozilla.org/logviewer?job_id=320268239&repo=autoland&lineNumber=2819
failure log: https://treeherder.mozilla.org/logviewer?job_id=320270436&repo=autoland&lineNumber=4399
[task 2020-10-30T16:39:39.580Z] 16:39:39 INFO - TEST-INFO | Main app process: exit 0
[task 2020-10-30T16:39:39.580Z] 16:39:39 INFO - TEST-INFO | LeakSanitizer | To show the addresses of leaked objects add report_objects=1 to LSAN_OPTIONS
[task 2020-10-30T16:39:39.580Z] 16:39:39 INFO - TEST-INFO | LeakSanitizer | This can be done in testing/mozbase/mozrunner/mozrunner/utils.py
[task 2020-10-30T16:39:39.580Z] 16:39:39 ERROR - TEST-UNEXPECTED-FAIL | LeakSanitizer | leak at nsDNSAsyncRequest::OnResolveHostComplete, nsHostResolver::ResolveHost, nsDNSService::AsyncResolveInternal, mozilla::net::nsSocketTransport::ResolveHost
[task 2020-10-30T16:39:39.580Z] 16:39:39 ERROR - TEST-UNEXPECTED-FAIL | LeakSanitizer | leak at Malloc, nsTArray_base, nsTArray_Impl, AppendElement
[task 2020-10-30T16:39:39.581Z] 16:39:39 ERROR - TEST-UNEXPECTED-FAIL | LeakSanitizer | leak at nsHostResolver::InitLoopbackRecord, nsHostResolver::ResolveHost, nsDNSService::AsyncResolveInternal, mozilla::net::nsSocketTransport::ResolveHost
[task 2020-10-30T16:39:39.581Z] 16:39:39 ERROR - TEST-UNEXPECTED-FAIL | LeakSanitizer | leak at nsHostResolver::InitRecord, nsHostResolver::InitLoopbackRecord, nsHostResolver::ResolveHost, nsDNSService::AsyncResolveInternal
[task 2020-10-30T16:39:39.581Z] 16:39:39 INFO - runtests.py | Application ran for: 0:03:12.032371
[task 2020-10-30T16:39:39.581Z] 16:39:39 INFO - zombiecheck | Reading PID log: /tmp/tmpG8b_1Vpidlog
*Other failure log: https://treeherder.mozilla.org/logviewer?job_id=320268239&repo=autoland&lineNumber=2819
Comment 9•4 years ago
|
||
bugherder |
Assignee | ||
Updated•4 years ago
|
Comment 10•4 years ago
|
||
Belén, you marked this bug as P1, do you intend to request an uplift in 83 beta or can it ride the 84 train? Thanks
Updated•4 years ago
|
Updated•4 years ago
|
Description
•