1331103 - indexedDb.open profile schema too high error cannot be silently caught, always thrown

Status: RESOLVED DUPLICATE of bug 1246615

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

Description

[jasonpang2011]

Attachment: indexedb_error.html

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

Steps to reproduce:

Note: Two versions of Firefox are needed to reproduce the profile schema too high error.

1. Open the attached HTML file in Firefox Aurora (Nightly). It's required to open this file in a higher version of Firefox.

2. Open the attached HTML file in Firefox Stable. It's required to open this file in a lower version of Firefox than the version in step #1.

3. Observe a console log message showing a caught error, but a second UnknownError being uncaught even though I've caught the error. 

See Image of Error: https://i.imgur.com/IT8zo0I.png
See Image of Error Source & Code: http://i.imgur.com/1NXhSja.png

Firefox Version: 50.1.0
Mac OS X: 10.11.6


Actual results:

An UnknownEvent error is correctly fired on request.onerror, but the caught error cannot be silently handled; the error is re-thrown.


Expected results:

The error caught through request.onerror should not continue to propagate.

Comment 1

[jasonpang2011]

Because customers with an IndexedDB schema-too-high Firefox profile don't know how to fix the issue themselves, and because the issue is permanent and doesn't fix itself over time, this causes error reporters like Sentry to track many instances of this issue and wastes report quotas on errors that are not fixable.

Some statistics from one of our customers:

- Customer info:
    - ~22,500 total devices subscribed (over last 4 months)
        - A device is a Firefox browser profile (can be multiple per PC)
    - 3,100 instances of this event (event can fire multiple times)
    - 285 unique IPs affected
        - If every single subscribed device has a unique IP, this gives a 1.3% error rate
- Error statistics:
    - Data collected from Dec. 14, 2016 - Jan 13, 2017 (about a full month)
    - Browser Occurrences
        - Firefox 45: 1%
        - Firefox 47: 1%
        - Firefox 48: 1%
        - Firefox Mobile 50: 1%
        - Firefox: 50: 99%
    - Operating System Occurrences
        - Windows 10: 37%
        - Windows 7: 22%
        - Mac OS X: 21%
        - Windows 8: 2%
        - Windows 8.1: 4%
        - Windows Vista: 1%
        - Windows XP: 6%
        - Ubuntu: 2%
        - Android: 1%

Comment 2

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to jasonpang2011 from comment #0)
> Created attachment 8826750 [details]
> indexedb_error.html
> 
> User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36
> 
> Steps to reproduce:
> 
> Note: Two versions of Firefox are needed to reproduce the profile schema too
> high error.
> 
> 1. Open the attached HTML file in Firefox Aurora (Nightly). It's required to
> open this file in a higher version of Firefox.
> 
> 2. Open the attached HTML file in Firefox Stable. It's required to open this
> file in a lower version of Firefox than the version in step #1.
> 
> 3. Observe a console log message showing a caught error, but a second
> UnknownError being uncaught even though I've caught the error. 
> 
> See Image of Error: https://i.imgur.com/IT8zo0I.png
> See Image of Error Source & Code: http://i.imgur.com/1NXhSja.png
> 
> Firefox Version: 50.1.0
> Mac OS X: 10.11.6
> 
> 
> Actual results:
> 
> An UnknownEvent error is correctly fired on request.onerror, but the caught
> error cannot be silently handled; the error is re-thrown.
> 

Triage meeting: we don't quite understand what it meant by "but the caught error cannot be silently handled; the error is re-thrown." Bevis, perhaps you could shed some light here?


> 
> Expected results:
> 
> The error caught through request.onerror should not continue to propagate.

Comment 3

[Bevis Tseng[:bevis][:btseng](Exited)]

(In reply to jasonpang2011 from comment #1)
> Because customers with an IndexedDB schema-too-high Firefox profile don't
> know how to fix the issue themselves, and because the issue is permanent and
> doesn't fix itself over time, this causes error reporters like Sentry to
> track many instances of this issue and wastes report quotas on errors that
> are not fixable.

Hi,

The try-catch clause is not useful because this unknown error was risen asynchronously to tell the developer that the error was caused by which asynchronous IDBRequest with the line number indicated in the console.
This is the default behavior of the IDBRequest.onerror callback if the event.preventDefault() is not called before the callback is returned:
http://searchfox.org/mozilla-central/rev/d3307f19d5dac31d7d36fc206b00b686de82eee4/dom/indexedDB/IndexedDatabaseManager.cpp#510-569

In your case, to prevent this error printed in the web console, you can change your implementation similar to the following:
var request = indexedDB.open("SOME_DATABASE", { version: 1, storage: "persistent" });

request.onsuccess = function(event) {
  let db = event.target.result;
  console.log("IndexedDB database opened successfully:", db);
};

request.onerror = function(event) {
>   event.preventDefault();
  var error = event.target.error;
  console.log("IndexedDB database open error:", error.name, error.message);
};

Hope this information is helpful to you!

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

As I understand comment 0, this is a variation of bug 1246615 in dealing with Firefox profiles that were created/updated by a more recent version of Firefox.  Specifically, comment 0 is from the time period when release=Firefox 50, Beta=Firefox 51, Aurora=Firefox 52, Central/Nightly=Firefox 53.  Since Firefox 52 (Aurora) corresponded to an IDB schema change from 24 to 25 (for all of: bug 964561, bug 1311466, bug 1302036), we would indeed expect that profiles used under 53 or 52 would generate errors like this under Firefox 50.

Note that IndexedDB does attempt to generate a more useful error, doing:
  IDB_WARNING("Unable to open IndexedDB database, schema is too high!");
But this uses nsContentUtils::LogSimpleConsoleError(string, string) which doesn't get mapped back to a specific tab/document, making it much less useful than it could be since I think that means it only is visible in the browser console, not the tab's devtools console.  The error returned is NS_ERROR_DOM_INDEXEDDB_UNKNOWN_ERR which is less useful since it manifests as shown in the first screenshot, https://imgur.com/IT8zo0I.

jasonpang2011, thank you so much for making the effort to identify and report the cause of the error, as well as providing concrete numbers that help us understand the scope of the impact of this problem!

Comment 5

[YF (Yang)]

This issue (comment 4) will break some add-ons when user downgrades to Firefox 54 or earlier versions for same profile.

I see this problem when try Nightly 55 for daily profile and downgrade to earlier versions due to compatibility issues. OneTab be broken, no toolbar button, like the database is corrupt, I try to fix it and failure, almost had to discard it. LastPass no longer remember my login email.