Open bennycode opened 8 years ago
I've seen issues with Firefox when opening two different database instances simultaneously. Also got the UnknownError. Have you had more success with older / newer firefox versions?
Seems you've got much trouble with unkownerror. Could it be that you are opening several database instances simultanously in your code? That should of course work according to spec, but it seems that there's a change to hit bugs when doing it.
@dfahlander - I am also hitting similar types of UnknownErrors in Safari. When logging out of our web application, UnknownErrors are intermittently thrown after deleting the database and then re-opening our Database connection.
I have determined that the error I posted is being caused by Safari 9 leaking indexeddb connections ðŸ˜. Safari 9 also does horrible things when you try to delete databases but have another tab to your app open. Luckily, Safari 10 Tech preview does not have either problem.
@dfahlander I've seeing the same error using Firefox V49.01 on Windows 10 with my app Clibu http://myclibu.com and with the first jsFiddle sample at: https://github.com/dfahlander/Dexie.js/wiki/Dexie - https://github.com/dfahlander/Dexie.js/wiki/Dexie
Please try that and you will hopefully get the same error.
UnknownError The operation failed for reasons unrelated to the database itself and not covered by any other error code.
MS Edge and Chrome are fine.
Updated: I've just tried FF V49.01 on another Windows 10 PC and I am not getting this error and Dexie is working fine. Which probably doesn't help much.
More info. It seems this isn't a Dexie.js issue at all, but something screwy in Firefox. I'm really over Firefox.
This sample snippet works fine on one PC but gives the same error as Dexie on the other PC.
var db;
var request = indexedDB.open("MyTestDatabase");
request.onerror = function(event) {
alert("Why didn't you allow my web app to use IndexedDB?!" + event.target );
console.log( 'onerror:', event.target )
};
request.onsuccess = function(event) {
db = event.target.result;
console.log( 'onsuccess' + event.target )
};
Final Update: I've reinstalled Firefox and the issue has gone away. Flakey, buggy Firefox!
Has anyone posted their issues on https://bugzilla.mozilla.org ? If not, I'll do it.
@dfahlander I haven't. It would likely carry more weight coming from you. I'm wasting so much time on getting code working in Firefox it isn't funny, in fact it is quite sad.
I've filed a bug at https://bugzilla.mozilla.org/show_bug.cgi?id=1310616. Note that the bug report is very fluffy so changes are low that they will be able to do anything about it.
If anyone has concrete reproducable Firefox bugs, please help the Firefox team to give them a way to trigger the bugs. If you haven't an account at Bugzilla, just send a comment to this issue with "Steps to reproduce", "Actual results" and "Expected results" and I'll try updating the issue accordingly.
@bennyn, do you know if your issue is still there in Firefox 49?
Thanks David. I put myself on the CC list.
I just checked the issue. I tried to login to my application (which uses Dexie) on FF48 (Windows):
I got the error with FF48. Then I upgraded to FF49. After doing the upgrade, I could login to my application (bug was not showing up).
So it seems to be related to FF48.
Great news. Thanks!
@nevf, since your issue was repaired after reinstalling Firefox 49, I assume we couldn't do so much of reproduction with it either.
Now that Firefox seems to have fixed bennyns issue, we could probably close this one as well as the one reported to Bugzilla. I'll keep them open for a while anyway in case someone has something more to add. Will close them in a week or so if nothing else shows up.
When listing IndexedDB bugs at Firefox bugzilla, there are some that potentially could be related to some instability issues on Firefox:
Thanks @dfahlander.
Just for the fun of debugging I downgraded my Firefox to version 48.0.2. Now I have the bug again and Dexie reports: UnknownError The operation failed for reasons unrelated to the database itself and not covered by any other error code
.
Is there a way for you to be more explicit about this bug, so that Dexie can give more information to the UnknownError
?
@bennyn Unfortunately, no. An internal error in firefox is nothing we could try to understand and explain to a user in generic terms.
I just read your comment on the bugzilla issue and it seems that the indexedDB database in firefox doesnt support downgrades.
If you have real life support cases where this happens, I would suggest you give your users a friendly message on UnknownError and allow them to clear out the client database entirely and start over. Or give them the option to upgrade firefox again instead.
I just read your comment on the bugzilla issue and it seems that the indexedDB database in firefox doesnt support downgrades.
But if I update my Firefox from v48 to v49, I can login to my account and use my database. So I don't think that it is about the database version?
No, I meant Firefox probably does some internal migration of the indexedDB database when migrating to Firefox 49. They've probably not covered up for downgrading Firefox and downgrading the internal database format. Just a guess though.
@dfahlander Just a heads up that I hadn't downgraded my version of Firefox. I had skipped a number of new releases however, in case that is at all relevant.
@nevf, I see. In your case the issue cannot be reproduced since it was repaired once you reinstalled firefox. It's probably still a bug but impossible for the mozilla team to dig into it so they had to close it. The reason for the bug could be anything from an upgrade bug to a corrupt installation file. If it happens again, you could maybe save your mozilla folder together with the location where it stores its data (where that is, I don't know) and submit it somehow to the firefox team together with a description of what version you upgraded from.
I just ran into the same problem with Firefox 53 on OSX and had to manually delete ~/Library/Mozilla/Firefox
to get past the error, clearing cached data through the various settings panes didn't make any difference.
If I see it again I'll try to find more details
I also briefly ran into this problem on Firefox 53 on Windows with my extension. Upgrading to Firefox 55 appears to have resolved the problem.
Seems that at least one Windows user of mine is hitting this problem on nightly build of Firefox 57. Trying to get it to repro two different machines (Windows and Linux) using running the same version was unsuccessful. My extension uses IndexedDB extensively and I've had so many problems with the Firefox implementation (Chrome runs just fine).
@FooSoft: Which version of Dexie are you using? Can you check if the problem still exsist when using Dexie v2.0.0-rc.1?
I wouldn't expect too much hope on a Dexie version, as the errors are from the native c++ code from Mozilla. There's no attempt to work around this error in Dexie. We only workaround some issues with idb2.0 in Mozilla, but that was not a crash bug.
@bennyn @dfahlander the error was encountered using the version of the library found here: https://github.com/dfahlander/Dexie.js/archive/v2.0.0-beta.10.zip. Unfortunately I was never able to reproduce this error myself so there is no way to see if anything will be different in the RC.
I did get some interesting information from my user:
open
on a database that does not even have anything in it yet). There is also only one version at this point.This finally worked for me after rm -rf ~/Library/Application Support/Firefox
and an uninstall of both Firefox and FirefoxNightly.
@bennyn does your databases contain WebCrypto CryptoKeys
? If this is the case, then this may be connected to a bug in Firefox that prevents adding indices to tables that contain CryptoKeys during migration. This bug leads reproducible to the aforementioned UnknownError
. There is an ongoing secure investigation about this that should resolve in the next few weeks hopefully:
https://bugzilla.mozilla.org/show_bug.cgi?id=1422335
If someone is interested I can put you on the CC list.
It sounds like many of these cases are related to downgrade issues. I maintain a log of schema changes we've made at lower levels that can be found at https://public.etherpad-mozilla.org/p/quota-manager-schema-change-log which indicates that a downgrade from 49 to 48 or 47 would break IndexedDB, as would the reported transition involving 55 and 53.
Even if the problem is understood, it's obviously very frustrating and non-obvious to users, developers, and QA. Firefox is attempting to mitigate cross-channel profile issues on https://bugzilla.mozilla.org/show_bug.cgi?id=1373244, address multiple versions of the same channel on https://bugzilla.mozilla.org/show_bug.cgi?id=1374227, and improve our handling of breakage in the IndexedDB subsystems in https://bugzilla.mozilla.org/show_bug.cgi?id=1296825 (although there will be a family of fixes related to that specific handling mechanism). This is part of a concerted effort to improve resiliency of our persistent storage handling, but at this point a conservative estimate is Firefox 60 for comprehensive fixes. (59 is currently in development, and should see many of the fixes, but given holidays, drift is likely. See https://wiki.mozilla.org/RapidRelease/Calendar for more information on Firefox's release schedule for context.)
One downgrade related tidbit is that except for QuotaManager-subsystem changes that don't support downgrades, Firefox's IndexedDB implementation will let you delete the database via the IndexedDB API and re-create it, even if you can't open it.
I have the same issue when using YJS and IPFS on Firefox Quantum 57.0.2 (64-bit) on Archlinux
We are using Dexie.js in our web application and we noticed some errors when accessing our existing database through Dexie in Firefox 47 and Firefox 48.
On Mac OS we get this strange error:
IndexedDB complains about
ActorsParent.cpp
and on Windows we get the following error:Have other users noticed similar problems?