Open Bug 1893821 Opened 2 months ago Updated 2 months ago

IndexedDB in Private Browsing Mode does not work in Web Extensions

Categories

(WebExtensions :: Storage, defect, P3)

Firefox 125
defect

Tracking

(firefox125 affected, firefox126 affected, firefox127 affected)

Tracking Status
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.

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.

Product: Firefox → WebExtensions

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.

Status: UNCONFIRMED → NEW
Ever confirmed: true

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).

See Also: → 1841806

FYI this topic has been discussed in the WECG before, at https://github.com/w3c/webextensions/issues/534

Severity: -- → S4
Component: Untriaged → Storage
Priority: -- → P3
Whiteboard: [wecg]
You need to log in before you can comment on or make changes to this bug.