1893821 - IndexedDB in Private Browsing Mode does not work in Web Extensions

Status: NEW

(WebExtensions :: Storage, defect, P3)

Description

[Akoki]

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

[BugBot [:suhaib / :marco/ :calixte]]

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

[Alex Cornestean]

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

[Luca Greco [:rpl] [:luca] [:lgreco]]

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

[Rob Wu [:robwu]]

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

Comment 5

[Akoki]

Just run extension's BACKGROUND SCRIPT the same way as by default, when "Always use private browsing mode" is disabled.

Run extension's background script in non incognito context, when "Always use private browsing mode" is enabled. That's all.

I see no problem of this simple fix.

It's how the extensions work in common mode.

In common mode when a browser opens an incognito window the extension works with that incognito window's tab fine.
There are no problems with that.
The background script is working in non incognito context and it can communicate with the incognito tabs.
In particular, the bg script can communicate with the extension pages opened in incognito tabs, which can't use IndexedBD, but it's not a problem, since I can send a message to the bg script to do some actions with IndexedBD and get the response. But this is a problem for "Always use private browsing mode" mode, because in this mode the bg script is also running in the incognito context, there is no way to operate with IndexedBD.

---

"Always use private browsing mode" option should not affect on extension's background scripts, only on tabs (extension's tabs too).

---

The current Firefox behavior is wrong, because Firefox does not support extension's split mode. But it currently works like the extension is with the split mode enabled. That is wrong.
The currecet behavior — to run the background script in incognito context with "Always use private browsing mode" is enabled — is only suited if where were "incognito": "split" in the extension's manifest.json file.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is set to S4. However, the following bug duplicates have higher severity:

• Bug 1427986: S3
• Bug 1955668: S3

:rpl, could you consider increasing the severity of this bug to S3?

For more information, please visit BugBot documentation.

Comment 9

[Harveer Singh]

Just to add a more general reminder here that extensions are by-default disabled in private browsing mode (https://support.mozilla.org/en-US/kb/extensions-private-browsing). Users can toggle to enable/disable as per above support page.

Comment 11

[david]

Thanks for pointing me here, Andrew.

Because of this limitation, 1Password just just doesn't allow users to use their extension in private browsing mode, they show an error telling users to turn it off. And MetaMask doesn't work at all right now in private browsing mode (I'm shipping a workaround soon that disables the feature that replies on indexedDB).

The reason MetaMask uses both storage.local and indexedDB is because neither is reliable enough for our needs, so we started using indexedDB as a backup storage area for only the most important data. We often see installations with databases that are unreadable, likely due to failing hardware (bad drives, RAM, power faults, disk full, etc) corrupting the data at rest - not necessarily issues with Firefox itself, so a backup helps. We've noted some success in mitigating db corruption using this backup on Chromium browsers.

Not allowing us to use indexedDb will ultimately result in critical data loss for some users (ultimately this is still the users fault when this happens, as we require all users to keep a backup of key information, but many don't).

In our community forums users have suggested to others who have recently experienced this issue to just stop using Firefox. We love our Firefox users and so we'll disable the automatic backup feature ASAP to keep them on Firefox, but it'd be really great for us, and them, if you'd consider bumping this issue in priority.