IndexedDB in Private Browsing Mode does not work in Web Extensions
Categories
(WebExtensions :: Storage, defect, P3)
Tracking
(firefox125 affected, firefox126 affected, firefox127 affected)
People
(Reporter: firefboxer, Unassigned)
References
Details
(Whiteboard: [wecg])
Steps to reproduce:
- "about:preferences#privacy"
- "Use custom setting for history"
- "Always use private browsing mode"
- Open any extension's option page / inspect a background script
- Run the follow code:
let request = window.indexedDB.open("demoDatabase", 1);
request.onerror = function() {
console.log(request.error);
};
Actual results:
DOMException: A mutation operation was attempted on a database that did not allow mutations.
Expected results:
It should work. It already works for usual sites, since the related bug was already fixed: https://bugzilla.mozilla.org/show_bug.cgi?id=1639542
but not for web extensions.
I need to use IndexedDB
instead of chrome.storage.local
in a web extension to store a user's data.
IndexedDB
is more suited for storing of a large count of entries than chrome.storage.local
.
Comment 1•2 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•2 months ago
|
||
Hello,
I reproduced the issue on the latest Nightly (127.0a1/20240428214249), Beta (126.0b6/20240426091720) and Release (125.0.2/20240419144423) under Windows 10 x64 and Ubuntu 22.04 LTS.
While in permanent Private Browsing Mode, with the extension allowed to access Private Windows, running the code from Comment 0 in the extension console will throw the mentioned error.
Comment 3•2 months ago
|
||
This is currently the expected behavior, see Bug 1841806.
With Bug 1639542 IndexedDB data for instances created in private browsing globals is going to be encrypted with a key that isn't persistent on disk (so that the data stored in a previous private session isn't going to be readable in a new browser session), unfortunately when that behavior have been enabled in extension pages some extensions (and in particular adblockers) have hit a regression (e.g. see Bug 1841806 comment 5).
Comment 0 states that they would like to store data in IndexedDB but re-enabling encrypted IndexedDB in extension pages running in permanent browsering mode would still make the data stored non readable anymore after a browser restart and so it doesn't seem it would be helping with that use case. On the contrary browser.storage.local API in Firefox still uses an IndexedDB backend and that API is available and works also in private browsing mode (and so that seems to be a better fit for the use case briefly mentioned in comment 0).
Comment 4•2 months ago
|
||
FYI this topic has been discussed in the WECG before, at https://github.com/w3c/webextensions/issues/534
Description
•