Don't assume the dom.storage.next_gen pref is live
Categories
(Core :: Privacy: Anti-Tracking, enhancement, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox70 | --- | fixed |
People
(Reporter: ehsan.akhgari, Assigned: ehsan.akhgari)
References
Details
Attachments
(1 file)
Here: https://searchfox.org/mozilla-central/rev/9eb2f739c165b4e294929f7b99fbb4d90f8a396b/dom/localstorage/LocalStorageCommon.cpp#41 we read the value of the pref at startup only once and never update it again. This affects e.g. what window.localStorage returns.
However we have tests in the tree like https://searchfox.org/mozilla-central/rev/9eb2f739c165b4e294929f7b99fbb4d90f8a396b/toolkit/components/antitracking/test/browser/browser_partitionedLocalStorage_events.js#67 which are written as if dom.storage.next_gen were a live pref!
Is this pref not being live intentional? Can we convert it into a live pref so that these tests actually test the thing they think they are testing rather than a combination of the new/old LS backends?
Comment 1•6 years ago
|
||
It's intentional. It would be really hard to make it a live pref.
| Assignee | ||
Comment 2•6 years ago
|
||
Interesting! So attempting to set this pref inside a browser-chrome test is completely broken, right? I see inside the debugger that the code is instantiating the old LS backend while the test is thinking the new backend is being tested...
Comment 3•6 years ago
|
||
I was thinking we might be able to make it work via nsIQuotaManagerService::Reset()
Comment 4•6 years ago
|
||
Andrew, do you have time to work on it?
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
| Assignee | ||
Comment 5•6 years ago
|
||
We talked about this at the all hands and decided to morph the bug into fixing our test to not assume the pref is live.
| Assignee | ||
Updated•6 years ago
|
| Assignee | ||
Comment 6•6 years ago
|
||
Updated•6 years ago
|
Comment 8•6 years ago
|
||
| bugherder | ||
Description
•