indexedDB broken - UnknownError - Error opening Database

NEW
Assigned to

Status

()

defect
P2
normal
6 years ago
a day ago

People

(Reporter: avitte, Assigned: tt)

Tracking

(Blocks 3 bugs, {dataloss, DevAdvocacy})

25 Branch
x86
Windows Vista
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: DWS_NEXT)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

6 years ago
User Agent: Mozilla/5.0 (Windows NT 6.0; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release)
Build ID: 20131112160018

Steps to reproduce:

I don't know how to reproduce it exactly because for now indexedDB is broken and whatever I do, trying to open/create a Database, I get:

[17:46:53.492] UnknownError @ https://xxx.js:8262
[17:46:53.492] "Error opening database" 

It happened after trying to encrypt large files doing:

Blob --> worker --> slice Blob --> encrypt chunk --> postMessage chunk --> collect chunks --> store new Blob([encrypted Blob, chunks]) in IDB every 2MB of chunks where encryptedBlob is the already encrypted Blob part retrieved from IDB

'store tasks' are queued and executed sequentially, each one executing after the previous one completed successfully (ie IDB write), but the implementation is under testing and maybe not exactly correct, so I suspect concurrent access on IDB.


Actual results:

IDB is broken, it's not limitated to the Database that created the issue, it can not be used any longer.
(Reporter)

Comment 1

5 years ago
It seems to be broken only for the domain that created the problem, impossible to open/create Databases any longer, deleteDatabase does not work, I tried Nightly too, nothing to do...

How can I clear/reset IDB?
(Reporter)

Comment 2

5 years ago
See #945281 for a reduced test case.

I still don't know exactly how to reproduce it but maybe the issue appears while doing something between console.log('get') and onsuccess (clearing the page, relaunching the same script...)
Component: Untriaged → DOM: IndexedDB
Product: Firefox → Core
(Reporter)

Comment 3

5 years ago
This is happening again, while opening an already created database on a specific domain, I systematically get 'Unknown Error'.

While I still don't know the cause, the problem was recurent and could be solved deleting indexedDB files, but now it seems impossible to revert, deleting files in indexedDB profile directory does not work, deleting indexedDB directory does not work either.

So on this domain indexedDB can not be used any longer, thanks to let me know what to do to identify the problem and how to recover.
(Reporter)

Comment 4

5 years ago
Update: clearing the file related to the domain in storage/persistent did allow to reuse indexedDB for that domain (the indexedDB directory seems not to be used any longer (??))

Is there not a simple way to clear indexedDB?
If you want to delete *all* the data that the web site has stored on your computer you can use the "Page Info" feature to do it. See https://support.mozilla.org/en-US/kb/page-info-window-view-technical-details-about-page#w_maintain-offline-storage to see the controls. You can click the "Clear Storage" button to remove the databases.

Sorry that this particular form of storage is difficult to clear, there are bugs open on trying to improve our UI.
(Reporter)

Comment 6

5 years ago
Sorry, I must be misreading the link you provided, where is the "Clear Storage" button?

What about "unknown error"? I have seen other bugs related to it but this does not seem to apply to my case, how to track this?
(In reply to Aymeric Vitte from comment #6)
> Sorry, I must be misreading the link you provided, where is the "Clear
> Storage" button?

It should show up in the permissions list in the "Maintain Offline Storage" section if the page has any data stored in indexedDB.

> What about "unknown error"? I have seen other bugs related to it but this
> does not seem to apply to my case, how to track this?

Sorry, I didn't read much past "Is there not a simple way to clear indexedDB?". This part will be harder to figure out.

Anything unusual about your profile location? Is it on a network drive or anything like that?
(Reporter)

Comment 8

5 years ago
I still don't see the "clear storage" button in permissions for a site that has indexedDB data stored, even with Nightly, maybe it will come later...

Nothing unusual with my profile location, this happens with http://www.peersm.com project, periodically the database gets broken and I can not figure out why for now.
Posted image screenshot.jpg
This is what the dialog should look like if the web site is actually storing data. The 'Clear Storage' button will be not appear if there is no data being stored.
(Reporter)

Comment 10

5 years ago
Ah, OK, not very intuitive to find it...
(Reporter)

Comment 11

5 years ago
Database broken is really happening very often, I still don't know the cause, any advise to investigate this?
(Reporter)

Comment 12

5 years ago
If you activate the private navigation mode (options/privacy), disable history and cookies then you get the very same behavior, indexedDB can't be accessed, I don't know if it is related to the cause of this bug but it seems similar.

This raises another question: how do we globally forbid any type of local storage or ask for permission?

Right now you can do it on a per site basis using the "page info" but by default all different types of local storage do not ask you anything, I don't find it normal at all, that's a security issue, any site can store whatever it likes, and I can not find where to force the browser to ask for permission for anything stored

Comment 13

5 years ago
I can confirm this database corruption though I am not sure if it is related - it might. I am using the database for large amounts of chunks of binary data. After using "clear recent history" with option everything but cookies, the database was completely corrupted with "unknown errors" popping around just for trying to open the database. Only a rm -rf in the appropriate storage directory (deleting all persistent storage for that domain) allowed indexdb access again.
I think this is what we're seeing with the new Thimble for some users in Firefox, for example: https://github.com/mozilla/thimble.webmaker.org/issues/1031#issuecomment-137113124

We host the filesystem in IndexedDB, and for some Firefox users, it just seems get corrupted right away:

Filer error: Object { name: "EINVAL", code: "EINVAL", errno: 18, message: "IndexedDB cannot be accessed. If pr…", stack: "e@https://mozillathimblelivepreview…" } bramble.js:3:4004

We haven't had reports of this in any other browser
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to David Humphrey (:humph) from comment #14)
> I think this is what we're seeing with the new Thimble for some users in
> Firefox, for example:
> https://github.com/mozilla/thimble.webmaker.org/issues/1031#issuecomment-
> 137113124
> 
> We host the filesystem in IndexedDB, and for some Firefox users, it just
> seems get corrupted right away:
> 
> Filer error: Object { name: "EINVAL", code: "EINVAL", errno: 18, message:
> "IndexedDB cannot be accessed. If pr…", stack:
> "e@https://mozillathimblelivepreview…" } bramble.js:3:4004
> 
> We haven't had reports of this in any other browser

Has there been any progress on this? I am seeing the same type of error and only in Firefox.

Comment 16

3 years ago
I just wanted to confirm we've been getting this error for at least a year, probably more, throughout several versions of Firefox.

At one point the indexedDB gets corrupted and any operation on it results in "UnknownError", with no possibility of fixing this. 

Please note that in this kind of situation, _there is no_ "Clear Storage" button available in Page Info.

Comment 17

3 years ago
I forgot to mention that this corrupts IndexedDB for all websites, not just the IndexedDB storage for the particular page...

Comment 18

3 years ago
One last comment, and I apologize for not writing a single one when I was sure I was going to finish. Reading through a couple of other related bugs, I realized in my case this was related to opening Firefox Nightly (to check a fix for an unrelated bug) and going back to the stable Firefox version. 

I.e. my case seems to https://bugzilla.mozilla.org/show_bug.cgi?id=1092090

The solution for this was to go to `about:support` to find my Profile Folder and to delete the contents of the `storage` folder from my profile.

Comment 19

3 years ago
I had this problem for the first time tonight also, and searching for it led me here (from https://bugzilla.mozilla.org/show_bug.cgi?id=944918).

I can confirm this happened after attempting the Firefox Nightly.  

danburzo's workaround to wipe the `storage` folder from the profile seems to have resolved it.

Comment 20

3 years ago
Sorry for the tracker spam, but the above is incorrect ... I found this issue via 1092090.

https://bugzilla.mozilla.org/show_bug.cgi?id=1092090

Possible duplicate.

Comment 21

2 years ago
At least one of our WebExtension users also ran into this problem a couple days ago. IndexedDB open was throwing "Unknown Error" and restarting Firefox or removing/reinstalling the WebExtension did not fix it. The user fixed it by creating a new profile but I guess the "delete storage folder" would have done the trick.

This is very critical problem though because it wipes out all data and fixing it requires extra work from the user.

Comment 22

a year ago
Hello,
I'm author of GroupSpeedDial and my users are reporting this bug all the time. Mostly after Firefox upgrade. I'm trying to find some pattern there but really cannot see any.

As a solution Firefox Reset feature works well - fixing users profile including database engine (IndexedDB) and keeping passwords and bookmarks.

If anybody knows something more about this issue, please let me know!
Juraj, do you see or your users see anything related to QuotaManager or IndexedDB in the browser console?

Comment 24

a year ago
Hello Jan. I'm not able to reproduce the issue and it's hard to get debug logs from users even if I send them detailed steps (I will post them here once I get any).
What I have is an error reported by the IdexedDB error handler:
`e.target.error.name`: 'UnknownError'
`e.target.error.message`: 'The operation failed for reasons unrelated to the database itself and not covered by any other error code'

If I can get better errors from my add-on, please let me know.
Priority: -- → P2

Comment 25

a year ago
Hi, 
I am a developer of Tab Session Manager.
Replacing the storage system with IndexedDB, the same problem was reported from several users.
https://github.com/sienori/Tab-Session-Manager/issues/210

The errors that occur are the same.
> `e.target.error.name`: 'UnknownError'
> `e.target.error.message`: 'The operation failed for reasons unrelated to the database itself and not covered by any other error code'

In that user's profile, it seemed that another service using IndexedDB could not be used.
Sample of IndexedDB: http://www.tohoho-web.com/html5/indexed_db_api_sample.html

I hope this problem will be solved.
keep this on your radar
Flags: needinfo?(jvarga)

Comment 27

a year ago
danburzo's solution was effective.
>The solution for this was to go to `about:support` to find my Profile Folder and to delete the contents of the `storage` folder from my profile.
I posted a solution for users of my extension.
https://github.com/sienori/Tab-Session-Manager/wiki/IndexedDB-Error
(Reporter)

Comment 28

a year ago
More than 5 years... this bug might survive us...

I don't know if this is related but I have another issue since probably the last upgrade

Opening the database on http://peersm.com/peersm now returns an error with only one argument isTrusted:true (as you can see in the log window), which looks quite strange

Could someone else try to see if this is specific to me? I did not change anything and this was still working recently, this is still working with Chrome, removing modules etc did not change anything

I don't know exactly how to remove the storage manually, I can't access the permissions tabs, I see no storage folders and the console tells me that I have nothing stored in indexedDB (and others), is there a way to reset this?
(Reporter)

Comment 29

a year ago
Adding the needinfo flag since this strange (mis)behavior could be important

Comment 30

a year ago
Regarding this bug, I'm receiving about 3 reports of this bug every week and those that reply to my questions usually falls under one of these reasons:

1) running some cleaning or optimizing software, for example CCleaner, BleachBit, Wise Disc Cleaner, ZHP Cleaner, Wisecleaner. Regarding popular CCleaner, reported versions were quite old: 5.03.5128 and 5.28.

2) running some special (less known) anti-virus or anti-malware software, like Malwarebytes or SUPERAntiSpyware. However only very few people reported this and was not able to reproduce it (but it may be related to data stored in the db, like some URL that is flagged as malware...).

3) downgrading your Firefox profile - if you execute any Firefox older than 57, then your profile gets instantly corrupted! This is often the reason - users using 56 or ESR versions decides to upgrade to 57+, they see half of their add-ons doesn't exists anymore, so they downgrade back and BAM! Database corrupted.

4) there are some rare cases when profile gets corrupted during the Firefox upgrade.

5) few people reported that only database of my add-on was corrupted and other add-ons / pages using IndexedDB were still working (I'm testing this on this page (db log is in bottom left corner): http://mdn.github.io/to-do-notifications/)

Regarding fixing it, if only one database is corrupted, then you may need to just remove specific database (dropping DB using API will fail, so you need to do it manually on your hard drive in profile\storage\default\<folder with db>).
If your whole IndexedDB engine is corrupted, the only option may be resetting your profile (consider setup Firefox Sync. before):
https://support.mozilla.org/en-US/kb/refresh-firefox-reset-add-ons-and-settings
(Reporter)

Comment 31

a year ago
1- I am not in cases 1 to 5 (except 4 maybe)

2- There is nothing in storage/default regarding peersm db, the only thing I do often is to kill FF via the task manager when it's eating too much memory (but if something gets corrupted, then it should be somewhere at least)

3- using to-do-notifications leads to 'Error loading database'

For now I don't want to reset FF, I reported this bug and if I take some time now (although I don't have a lot) to write again (although I don't really care for my current projects) this is because I think that the issue is serious (error object with only one property is normal?)

Comment 32

a year ago
KDE bug 
393960 – Dolphin should not write a .directory file in a db directory that is used by IndexedDB
<https://bugs.kde.org/show_bug.cgi?id=393960>

An offending .directory file may be added whilst Firefox runs, without symptoms becoming evident in Firefox. 

As far as I can tell: things will fail when Firefox is next started, or restarted.

Comment 33

a year ago
Screen recording: https://photos.app.goo.gl/MLC2x2sbR5veqLXb9 (for some reason, I could not attach it to Bugzilla). 

In this example, the offending file is in the db directory of: 

moz-extension+++039dbea5-61d3-4fcd-8f36-2c18cbe6304c

– and the page at <http://mdn.github.io/to-do-notifications/> shows: 

> To do list with Notifications and Vibration

> - App initialised. 
> - Error loading database. 

After removal of the file, a simple reload of the page is free from the error message.

Comment 34

a year ago
Without quitting Firefox, careful use of 

find . -name .directory -delete

----

Prior to running the command, the test page shows an error message. 

After removal (deletion) of the offending files and a reload of the page, no error message.
(Reporter)

Comment 35

a year ago
I did remove everything in storage/default (even if nothing was related to peersm), before this I deleted a moz-extension dir, still not working, then I noticed that idb directories were empty for about+newtab, moz-safe-about+home (but still no peersm dir)

And now it's working, I see the peersm dir and default dirs are back with a non empty idb dir (including the moz-extension dir)

The least we can say is that something is not square... I did not work on this since some time and did not touch anything, so probably the latest upgrade caused this

Comment 36

a year ago
(In reply to Aymeric Vitte from comment #35)

> … storage/default …

In the example below a .directory file elsewhere prevented <http://mdn.github.io/to-do-notifications/> from working. After command line deletion of both files, I reloaded the page: no error message. 

----

[grahamperrin@momh167-gjp4-hpelitebook8570p-freebsd] ~/.mozilla/firefox/q0ogc2x6.everyday-1522426377402/storage% find . -name .directory -print
./temporary/moz-extension+++6e3a92de-56b9-4ce9-804d-09ed0448642c/.directory
./.directory
[grahamperrin@momh167-gjp4-hpelitebook8570p-freebsd] ~/.mozilla/firefox/q0ogc2x6.everyday-1522426377402/storage% find . -name .directory -delete

----

(In reply to Graham Perrin from comment #32)

> KDE bug 
> 393960 – Dolphin should not write a .directory file in a db directory that is used by IndexedDB


Now, I _guess_ that IndexedDB expects, or requires, non-interference with the contents of directories. And not just the 'db' directory. 

To be honest I haven't taken time to look into IndexedDB specifications/requirements (I'm just an end user, tester).
Keywords: dataloss
Marking as DevAdvocacy bug, since we're seeing things like this pop up in the wild: https://github.com/sienori/Tab-Session-Manager/wiki/IndexedDB-Error
Keywords: DevAdvocacy

Comment 38

10 months ago
(In reply to Dietrich Ayala (:dietrich) from comment #37)
> Marking as DevAdvocacy bug, since we're seeing things like this pop up in
> the wild: https://github.com/sienori/Tab-Session-Manager/wiki/IndexedDB-Error

Yep, for another example: https://www.reddit.com/r/Enhancement/wiki/faq/indexeddb_failure

Appreciate the change / add of that marker.
:dietrich pinged me about this.  There are two levels of mitigations as it relates to the existence of ".directory" files, both relating to IsOSMetadata[1]:
a) Whitelist ".desktop" and any other known byproducts of file managers.
b) Whitelist everything starting with a "." as that's convention for "ignore this file".  This is made somewhat awkward by our use of ".metadata" and ".metadata-v2" for semantically relevant files in the directory tree.

At a higher level, we still want to wipe origins for which we believe QuotaManager's directory structure has been corrupted rather than breaking like this, but we really shouldn't be mistaking dot-files left around by file managers as corruption.


There are several different causes of IndexedDB breakage discussed on this bug, many of which are tracked or have been improved elsewhere, but I do want to address them explicitly:
- Comment 1 through Comment 11: Breakage of a specific QuotaManager origin.  This can happen due to the structured clone and/or IndexedDB schema version changes.  It can also happen for extra files showing up in the directory.
- Comment 12 about private browsing breaking IDB or very strict cookie storage settings breaking IDB is expected and intentional on behalf of the user; we disable IDB in those cases, it's not broken.
- Comment 13 about clear recent history is a little bit of a red herring because clear recent history did not actually wipe IndexedDB at that time.  The breakage was likely at a QuotaManager or IndexedDB level, possibly due to downgrade.
- Comment 14 through comment 17 are unclear, likely due to downgrade.
- Comment 18 through comment 20 are explicitly referencing downgrade issues.  These likely coincided with schema changes that were not downgrade compatible.  https://public.etherpad-mozilla.org/p/quota-manager-schema-change-log is still the most readable version of our history of schema changes that can cause such issues.
- Comment 21 through comment 24 are possibly general downgrade issues.
- Comment 25 is most likely an issue at the QuotaManager level.
- Comment 27 through comment 31 likely involve unexpected files in the storage/ sub-tree because there haven't been a lot of schema changes in that time range.
- Comment 35 might be an interesting failure mode related to missing files?  Or it could be the same as...
- Comment 32 through comment 36 relate to the ".desktop" file making QuotaManager unhappy.  I think IndexedDB should be fine with that file.


I propose we morph this bug to be about implementing mitigation B.  While mitigation A is more conservative, it's clear we've had a systemic issue here for some time, and I think it's appropriate to err on the side of being overly accepting of dot-files.  I'm going to toggle :janv's needinfo to get a rising edge notification.


1: https://searchfox.org/mozilla-central/rev/42930ab9634ebf3f62aed60f7d1c1bf25c0bf00c/dom/quota/ActorsParent.cpp#1463
Flags: needinfo?(jvarga)
Flags: needinfo?(jvarga)
Flags: needinfo?(bugmail)

Comment 40

10 months ago
Yeah, thanks for this analysis. Being less strict is probably the way to go. I'm ok with B.
Flags: needinfo?(jvarga)

Comment 41

10 months ago
+1

Thanks folks. 

----

Two nits.


1) 

>  Platform: x86 Windows Vista

– it's no longer so specific. 


2) 

> Keywords: dataloss

If (as proposed, <https://bugzilla.mozilla.org/show_bug.cgi?id=944918#c39>) this bug morphs to implementation of the mitigation, then IIUC (correct me please, if I'm wrong) the effective end result will be no loss, in those cases. 

Unless, of course, the end user actively removes data without realising that workarounds exists. 


----

If the fix for this bug will be whitelisting, then _might_ it be the type of fix that can get into Firefox ESR 60.x?

Comment 42

10 months ago
Better solution will be to:

c) Stop blindly reading unknown files

because I can reproduce this problem with "desktop.ini", "this is my extension database" and "asdf" files. I can also speculate that antiviruses may create temporary files here when scanning database.
Re: comment 41, ESR uplift.  Yes, a simple white-list update can probably get uplifted to ESR.  More extensive fixes will likely not.

Re: comment 42:

To be clear, QuotaManager doesn't read unknown files.  The problem is that some code paths which enumerate the contents of the directory report an effectively fatal error if they find files that QuotaManager doesn't think should be there.

"desktop.ini" is a good file to point out, thank you.  We should absolutely whitelist that one as well as an inert file.  We also will, in another bug, be changing behavior when non-whitelisted unidentified files are found; we'll wipe the directory in question rather than permanently breaking until user action is taken to use "refresh Firefox" to create a new profile without the storage/ directory, or otherwise manually cleaning up the storage/ directory.

Re: anti-virus temporary files.  At least Microsoft's anti-virus seems to use the system's temporary directory for its temporary files.  If you can point us at any information on AV creating/leaving temporary files in the directories it is scanning, we'd definitely appreciate that as we address this family of problems.
Flags: needinfo?(bugmail)
Flags: needinfo?(bugmail)

Updated

9 months ago
Blocks: 1474562

Updated

9 months ago
No longer blocks: 1474562
See Also: → 1474562

Updated

8 months ago
Blocks: ss-SM

Updated

8 months ago

Updated

8 months ago
No longer blocks: ss-SM

Comment 44

8 months ago
Encountered this on upgrade to FF61.  Regular experiences of FF upgrades breaking core functionality without addressing years-old bugs in core software are the primary reason why I so strongly dislike forced "upgrades" in FF.

Updated

8 months ago
Blocks: 1482662

Updated

8 months ago
Assignee: nobody → shes050117
Whiteboard: DWS_NEXT
(Assignee)

Comment 45

7 months ago
I'll fix it in bug 1423917.
(Assignee)

Updated

7 months ago
Depends on: 1423917

Updated

6 months ago
Blocks: 1493262

Comment 46

5 months ago
These days I'm receiving many of these reports (like 2 per day) and some claims it happened right after normal Firefox upgrade. Users said - they see Firefox upgrading message and after that they see the broken database message in my add-on. One of them said that the error then disappears after restarting browser.

After each new Firefox release there is this wave of new users reporting this error to me. I'm pretty sure this is related to Firefox upgrade as well.

BTW there is this great page (I'm sending it to users to verify the bug) to test your storage that checks IndexedDB as well:
https://firefox-storage-test.glitch.me/

Comment 47

5 months ago
That page does need an update, though. Persistent storage is no longer done like that.
(In reply to brunoais from comment #47)
> That page does need an update, though. Persistent storage is no longer done
> like that.

The use of the term "persistent" was a bad naming-choice on my part.  It's a normal indexedDB database opened via `open("persistent", 1)` rather than the deprecated Firefox-specific `open(..., { storage: "persistent" })`.  "persistent" is intended to distinguish that it's left around for future runs of the test page as compared to the "transient" db that's created and immediately deleted as a test of whether IndexedDB is able to create new databases.
Flags: needinfo?(bugmail)

Comment 49

5 months ago
Oh, right. I misread the code. Sounds like my browser is broken....
IndexedDB UnknownErr: ActorsParent.cpp:600
Now to find the problem.... another headache.

Updated

5 months ago
Duplicate of this bug: 1504535
(Assignee)

Updated

5 months ago
See Also: → 1504535

Comment 51

3 months ago

Work status update for broken indexedDB bug fixes (Bug 944918, Bug 1423917) can be found in Bug 1482662.

Comment 52

3 months ago

I have a question.
Since October last year I'm getting some reports from my user where IndexedDB fails with message "Error: undefined".
In such case, restarting Firefox or whole PC doesn't help, however reinstalling my add-on helps. Also the error seems to be thrown only for some specific queries which fails every time, rest of them still works fine.

Is this related to this bug?
Also where is some info about "Error: undefined" error? Normally I get a full description, like "Error: An attempt was made to use an object that is not, or is no longer, usable".

Also in October I started to store image Blobs in the IndexedDB (maybe it's related).

(Assignee)

Comment 53

3 months ago

ni myself to answer comment 52

Flags: needinfo?(shes050117)
(Assignee)

Comment 54

3 months ago

(In reply to juraj.masiar from comment #52)

I have a question.
Since October last year I'm getting some reports from my user where IndexedDB fails with message "Error: undefined".
In such case, restarting Firefox or whole PC doesn't help, however reinstalling my add-on helps. Also the error seems to be thrown only for some specific queries which fails every time, rest of them still works fine.

Is this related to this bug?
Also where is some info about "Error: undefined" error? Normally I get a full description, like "Error: An attempt was made to use an object that is not, or is no longer, usable".

Also in October I started to store image Blobs in the IndexedDB (maybe it's related).

It seems like it's not related to because it's not an unknown error unless the message has been transformed (or, perhaps, checking if there are more information on browser console). The definition of the unknown error is here [1]. I don't think IndexedDB would pump out errors like "Error: undefined". (Should be at least be one type of errors on the list of [1]. e.g. UnknownError @ https://xxx.js:8262)

However, we should make messages of unknown errors better. Most of the time, message which developers can get is a bit vague. Here is the bug for tracking that [2].

Here, I intend to fix the majority of unknown issues on initialization. Hopefully, we can reduce the number of unknown errors for indexedDB here.

[1] https://heycam.github.io/webidl/#unknownerror
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1502077

Flags: needinfo?(shes050117)
(Assignee)

Comment 55

3 months ago

(In reply to Tom Tung [:tt, :ttung] from comment #54)

It seems like it's not related to because it's not an unknown error unless the message has been transformed (or, perhaps, checking if there are more information on browser console). The definition of the unknown error is here [1]. I don't think IndexedDB would pump out errors like "Error: undefined". (Should be at least be one type of errors on the list of [1]. e.g. UnknownError @ https://xxx.js:8262)

If the error message has been transformed (don't know which kinds of error it is), then it's really hard to say.

Comment 56

3 months ago

Thank you for the info!
So if I understand it correctly, I should just wait for better error reporting to be implemented in Firefox. Right?
Or is there anything else I can do to improve error reporting in my add-on?
Also the error reporting page on MDN is not very clear, there is even a TODO written in the code example :D
https://developer.mozilla.org/en-US/docs/Web/API/IDBRequest/onerror

objectStoreTitleRequest.onerror = function() {
  // If an error occurs with the request, log what it is
  console.log("There has been an error with retrieving your data: " + objectStoreTitleRequest.error);
  // TODO what about event parameter into onerror()? What will be inside of this event?
};
(Assignee)

Comment 57

3 months ago

(In reply to juraj.masiar from comment #56)

Thank you for the info!
So if I understand it correctly, I should just wait for better error reporting to be implemented in Firefox. Right?

Yes, we will definitely improve the error reporting on IndexedDB in the future.

I would also encourage logging more information since there are many possibilities to get "Error: undefined".
For instance, the reason could be in the Javascript level:

function foo(error) {
  console.log("Error: " + error); 
}

// should pass an argument
foo();

let object = {attrbute1: 1}; // dinfine object.attribut1 but doesn't define object.attribute2.
foo(object.attribute2);

Or is there anything else I can do to improve error reporting in my add-on?
Also the error reporting page on MDN is not very clear, there is even a TODO written in the code example :D
https://developer.mozilla.org/en-US/docs/Web/API/IDBRequest/onerror

objectStoreTitleRequest.onerror = function() {
  // If an error occurs with the request, log what it is
  console.log("There has been an error with retrieving your data: " + objectStoreTitleRequest.error);
  // TODO what about event parameter into onerror()? What will be inside of this event?
};

I guess logging the error message is good enough or you could simply log all the DOM exception like your example from MDN.
So, there are two options in my mind.

  • Option one is just like your example from MDN and it would show everything about that DOM exception.
  • Option two is to log message attribute (and maybe the name attribute as well) inside and you should get one of the error messages in this list [1] if the error comes from IndexedDB.

[1] https://searchfox.org/mozilla-central/source/dom/base/domerr.msg#60-77

Comment 58

3 months ago

Regarding the "Error: undefined" - I'm not building this kind of strings :), it must be coming from some browser API. And from what I can see in my method it can be only one of these these:

  1. browser.runtime.getBackgroundPage() - that I use to detect container / private window
  2. browser.runtime.sendMessage - that I use to get data from background script
  3. idbRequest.onerror = reject; - that I use to catch database errors - and it works fine for many other erros

So there is a chance it came from browser.runtime.sendMessage, although I'm skeptical.
I'm gonna change my error logging to be sure where was the error created. And I will add the 'name' and 'message' attributes.

Thank you for your help!

(Assignee)

Comment 59

3 months ago

(In reply to juraj.masiar from comment #58)

Regarding the "Error: undefined" - I'm not building this kind of strings :), it must be coming from some browser API. And from what I can see in my method it can be only one of these these:

  1. browser.runtime.getBackgroundPage() - that I use to detect container / private window
  2. browser.runtime.sendMessage - that I use to get data from background script
  3. idbRequest.onerror = reject; - that I use to catch database errors - and it works fine for many other erros

So there is a chance it came from browser.runtime.sendMessage, although I'm skeptical.
I'm gonna change my error logging to be sure where was the error created. And I will add the 'name' and 'message' attributes.

Thank you for your help!

No problem! Thank you for providing more information! And, it'd be useful if we can find out any other problem making initialization failure and fix them at once.

Per request of Luca Grego I am uploading the storage of an add-on of his that got corrupted during my recent upgrade to Firefox 66.0.2 (Mac OS X Mojave version 10.14.4 (18E226)).

Steps to reproduce the issue I am having:

  1. Download and build Simple Tab Groups from source (although I suspect any add-on would cause the same problem)
  2. Navigate to about:debugging and enable it if needed
  3. Load the built addon/dist/background.js using the Load Temporary Add-on button and take note of its UUID
  4. Open a terminal, cd to your profile directory, untar the attachment into an EXTRACTED subdirectory and cd back to your profile directory
  5. rsync the EXTRACTED data over that of the temporary add-on with a command likenewuuid=f2ae7be4-3368-0d40-a655-bc8e6fcff78e; rsync -av EXTRACTED/storage/default/moz-extension+++d5b1612f-bb2d-cf46-9278-eb78a95372e0\^userContextId=4294967295/idb storage/default/moz-extension+++${newuuid}\^userContextId=4294967295/; rsync -av EXTRACTED/storage/default/moz-extension+++d5b1612f-bb2d-cf46-9278-eb78a95372e0/idb storage/default/moz-extension+++${newuuid}/
  6. Back to the about:debugging page in Firefox, deactivate and reactivate the temporary add-on.

Expected result: An additional Simple Tab Groups icon shows up in the tab bar.

Actual result: An exception about it not being IndexedDB's fault pops up.

Additional steps to confirm that the problem is with storage.local and (presumably) not IndexedDB itself:

  1. Run sqlite3 on every *.sqlite file in the attached archive, and at the prompt, run PRAGMA integrity_check; to rule out an sqlite corruption issue
  2. From the about:debugging Firefox tab, clic Debug to start a debugger instance; click OK if prompted
  3. From the JS console of said debugger instance, evaluate browser.storage.local.get(null).then(console.log)

Expected result: a dump of the storage.local state for this add-on
Actual result: crashes with the same message as before.

As correctly surmised in up-thread, one cannot backtrack out of that situation by using browser.storage.local alone, and indeed browser.storage.local.clear() does not help.

(Assignee)

Comment 61

15 days ago

(In reply to Dominique Quatravaux from comment #60)

Thanks for the information, especially the STR! Will check that.

(In reply to Tom Tung [:tt, :ttung] from comment #61)

Thanks for the information, especially the STR! Will check that.

Hey Tom,

I gave it a look and it seems that the failure is not happening when the IndexedDB is opened, but the storage.local.get() API call is failing consistently when the IndexedDB cursor, used internally to retrieve all the stored value, reaches the item with key "groups".

I tried to retrieve that item directly by key, and that call is also failing consistently with the error:

IndexedDB UnknownErr: ActorsParent.cpp:565 2
UnknownError: The operation failed for reasons unrelated to the database itself and not covered by any other error code.

(but the values set on other keys can be retrieved just fine).

And so it seems that the issue may be triggered by the value set with that key, which is likely a quite big object when there are a bunch of groups with many tabs stored in it, but I don't know yet why it has been able to be stored and then fails to be retrieved.

Let me know if you notice something suspicious in those IndexedDB storage files that may be able to trigger the error raised when we try to retrieve that particular value, I'll still try to dig into it more (the data related to the storage.local IndexedDB database is in the directory named "moz-extension+++d5b1612f-bb2d-cf46-9278-eb78a95372e0^userContextId=4294967295").


As a side note related to the STR:

Instead of manually renaming the storage files, you could use the following slightly modified STR
(which tweaks the about:config preference to force the installed extension to use the UUID of the broken storage IDB directory):

  • create a new blank Firefox profile
  • install Simple Tab Group from AMO (https://addons.mozilla.org/en-US/firefox/addon/simple-tab-groups/)
  • open about:config in a tab, search for the "extensions.webextensions.uuids" preference, edit it and change the uuid value
    of the extension with id "simple-tab-groups@drive4ik" to match the UUID from the attached file (that is "d5b1612f-bb2d-cf46-9278-eb78a95372e0")
  • close Firefox
  • copy all the content of the "storage/default/" dir as it is, from the attached files into the "storage/default/" dir of the newly created profile
  • start Firefox on the modified profile
Flags: needinfo?(shes050117)

Well, I digged a bit more into the sqlite file of the database in the "broken value" state and I found something suspicious while inspecting the ".sqlite" file using the sqlite3 cli tool:

there are two files "referenced" by the data stored in this database, and they should be named 904 and 893

sqlite> select * from object_data;
1|0bvupCbdlvqFobcmf|||<
...
1|0hspvqt||.904|4294967296
...
1|0uivncobjmt||.893|4294967296
...

sqlite> select * from file;
893|1
904|1

But the files actually stored in the ".files" dir are not exactly matching what we would expect based on the content of the sqlite file:

> ls test-profile-1/storage/default/moz-extension+++d5b1612f-bb2d-cf46-9278-eb78a95372e0\^userContextId=4294967295/idb/3647222921wleabcEoxlt-eengsairo.files
893  903  journals

I tried to just copy the file 903 to a file named 904, as expected by the status in the sqlite file, and after that the "storage.local.get" calls are able to complete successfully (both when "groups" value is being retrieved by key or through the cursor).

It is also interesting to notice that the "groups" value wasn't that big, especially compared with the "thunmbnails" key:

> JSON.stringify(await db.get("groups")).length
1181104
> JSON.stringify(await db.get("thumbnails")).length
9183118

And so now the questions are:

  • how the IndexedDB can enter this kind of inconsistent state?
  • is there any particular reason why the "groups" value entered the inconsistent state but "thumbnails" one didn't?

Could be a similar problem as in bug 1517145.

Updated

14 days ago
Attachment #9055172 - Attachment is obsolete: true
The content of attachment 9055172 [details] has been deleted for the following reason:

Deleted by the request of ddurst

(In reply to Dominique Quatravaux from comment #60)

Created attachment 9055172 [details]
Corrupt IndexedDB storage possibly caused by this bug

Per request of Luca Grego I am uploading the storage of an add-on of his that got corrupted during my recent upgrade to Firefox 66.0.2 (Mac OS X Mojave version 10.14.4 (18E226)).

Thanks a lot for sharing the corrupted file, it has been very useful to inspect the internal state and get more insights about what kind of issue we have to investigate.

I asked to take the file down because in Comment 63 there are now detailed enough information to recover it from the corrupted state, and I wanted to be sure that the file wasn't available anymore on this bug, just as a precaution
(as a side note, you may also use comment 63 to recover your data from that database).

:ttung :jvarga let me know if you need the corrupted file to dig more into the underlying issue.

(Assignee)

Comment 67

9 days ago

(In reply to Luca Greco [:rpl] from comment #63)

sqlite> select * from file;
893|1
904|1


But the files actually stored in the ".files" dir are not exactly matching what we would expect based on the content of the sqlite file:

ls test-profile-1/storage/default/moz-extension+++d5b1612f-bb2d-cf46-9278-eb78a95372e0^userContextId=4294967295/idb/3647222921wleabcEoxlt-eengsairo.files
893 903 journals

Hmm, it seems it's a similar issue related to structedClone

See Also: → 1515069
(Assignee)

Comment 68

8 days ago

Based on comment 60, comment 62, and comment 63, I believe this is the same issue as bug 1519859.

Although :rpl in comment 63 provided a way to recover (thanks!), I would like to find out why the file_id in the sqlite table and the physical file are different as my first step.

(In reply to Luca Greco [:rpl] from comment #63)

I need to investigate more to answer these questions.

And so now the questions are:

  • how the IndexedDB can enter this kind of inconsistent state?
  • is there any particular reason why the "groups" value entered the inconsistent state but "thumbnails" one didn't?
(Assignee)

Updated

a day ago
See Also: → 1522188
(Assignee)

Updated

a day ago
Blocks: 1541370
(Assignee)

Comment 69

a day ago

I don't think this is an initialization issue because it won't block the initialization. Since the problem is really serious, I am putting it into another meta bug to track this issue. (I will definitely keep working on this.)

No longer blocks: 1482662
Flags: needinfo?(shes050117)
You need to log in before you can comment on or make changes to this bug.