1634328 - Firefox private window gives false positive for indexedDB causes lots of trouble for developers.

Status: RESOLVED FIXED

(Core :: Storage: IndexedDB, defect, P3)

Description

[Minkul]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4128.3 Safari/537.36

Steps to reproduce:

Firefox private mode does not support indexedDB. Okay, that might be for one of the good reasons Mozilla stands for.

But While testing for availability of indexedDB, private mode gives false positive.

While testing for indexedDB with following snippet FF private window should return undefined on window.indexedDB. But it doesn't. This creates lots of problems. One example might be: libraries like localforage tries to use indexedDB before falling back to localstorage.

In FF private mode we get this error: InvalidStateError: A mutation operation was attempted on a database that did not allow mutations.

Taken from: https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB

if (!window.indexedDB) {
    console.log("Your browser doesn't support a stable version of IndexedDB. Such and such feature will not be available.");
}

Above test doesn't give correct result on FF private mode.

FF private mode also seems to have problems while working with localstorage in conjunction with promise. I had to wrap the promise call with setTimeout to make it work on FF private mode.

Actual results:

FF private window gives false positive about usability of indexedDB.

Expected results:

If is not supported then FF private mode should signal indexedDB does not exist at all in both desktop and mobile.

Comment 1

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (non,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Comment 3

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

The priority flag is not set for this bug.
:johannh, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[Perry Jiang [:perry] [no longer employee, use ni?]]

FWIW I see the log statement in the snippet printed when I try to run it in private browsing (no exception thrown).

Comment 5

[Minkul]

Attachment: ff-indexeddb-false-positive-private.png

Comment 6

[Minkul]

Attachment: ff-indexeddb-works-regular.png

Comment 7

[Minkul]

(In reply to Perry Jiang [:perry] from comment #4)

FWIW I see the log statement in the snippet printed when I try to run it in private browsing (no exception thrown).

Thanks for attention to this issue.

if (window.indexedDB) {
    console.log("indexedDB is available");
}

var db;
var request = indexedDB.open("MyTestDatabase");

request.onerror = function(event) {
  console.log("Why didn't you allow my web app to use IndexedDB?!");
};

request.onsuccess = function(event) {
  db = event.target.result;
  console.log(db);
};

Taking code snippet from: https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB

FF private mode passes the test with window.indexedDB. Then it fails when trying to open a database later.

FF private mode should return falsy value against window.indexedDB test, so that we can detect unavailability of indexedDB as soon as possible.

I have run the snippet with stable 76.0.1 version. Screenshots are attached of both regular and private window.

Comment 8

[Daniel Veditz [:dveditz]]

Sorry for the 3 year late drive-by comment, but I believe this was an intentional compromise. A lot of sites checked for window.indexedDB with no intention to use it, only to try to detect Firefox in private browsing mode. By returning a value we preserve user privacy. Sites that intend to use IDB will run into the next error, but they already have to handle that because opening a DB can fail for other reasons (out of space, for example).

The "See Also" bug Simon linked to is nearly ready to ship so this will become a non-problem in a couple of months

Comment 9

[Rob Wu [:robwu]]

Fixed in 115 by bug 1831058.