944918 - indexedDB broken - UnknownError - Error opening Database

Status: RESOLVED FIXED

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

Description

[Aymeric Vitte]

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.

Comment 1

[Aymeric Vitte]

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?

Comment 2

[Aymeric Vitte]

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...)

Comment 3

[Aymeric Vitte]

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.

Comment 4

[Aymeric Vitte]

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?

Comment 5

[Ben Turner (not reading bugmail, use the needinfo flag!)]

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.

Comment 6

[Aymeric Vitte]

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?

Comment 7

[Ben Turner (not reading bugmail, use the needinfo flag!)]

(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?

Comment 8

[Aymeric Vitte]

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.

Comment 9

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Attachment: 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.

Comment 10

[Aymeric Vitte]

Ah, OK, not very intuitive to find it...

Comment 11

[Aymeric Vitte]

Database broken is really happening very often, I still don't know the cause, any advise to investigate this?

Comment 12

[Aymeric Vitte]

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

[mm]

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.

Comment 14

[David Humphrey (:humph)]

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

Comment 15

[José Antonio Márquez Russo]

(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

[Dan Burzo]

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

[Dan Burzo]

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

Comment 18

[Dan Burzo]

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

[Patrick S]

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

[Patrick S]

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

[voltron]

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

[juraj.masiar]

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!

Comment 23

[Jan Varga [:janv]]

Juraj, do you see or your users see anything related to QuotaManager or IndexedDB in the browser console?

Comment 24

[juraj.masiar]

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.

Comment 25

[Sienori]

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.

Comment 26

[Marion Daly [:mdaly]]

keep this on your radar

Comment 27

[Sienori]

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

Comment 28

[Aymeric Vitte]

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?

Comment 29

[Aymeric Vitte]

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

Comment 30

[juraj.masiar]

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

Comment 31

[Aymeric Vitte]

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

[Graham Perrin]

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

[Graham Perrin]

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

[Graham Perrin]

Attachment: Screen recording, 2018-05-07 15:10

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.

Comment 35

[Aymeric Vitte]

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

[Graham Perrin]

(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).

Comment 37

[Dietrich Ayala (:dietrich)]

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

Comment 38

[Steve Sobel]

(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.

Comment 39

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

: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

Comment 40

[Jan Varga [:janv]]

Yeah, thanks for this analysis. Being less strict is probably the way to go. I'm ok with B.

Comment 41

[Graham Perrin]

+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

[gwarser]

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.

Comment 43

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

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.

Comment 44

[WBT]

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.

Comment 45

[Tom Tung [:tt, :ttung]]

I'll fix it in bug 1423917.

Comment 46

[juraj.masiar]

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

[brunoais]

That page does need an update, though. Persistent storage is no longer done like that.

Comment 48

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

(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.

Comment 49

[brunoais]

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

Comment 51

[Robert AB]

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

Comment 52

[juraj.masiar]

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).

Comment 53

[Tom Tung [:tt, :ttung]]

ni myself to answer comment 52

Comment 54

[Tom Tung [:tt, :ttung]]

(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

Comment 55

[Tom Tung [:tt, :ttung]]

(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

[juraj.masiar]

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?
};

Comment 57

[Tom Tung [:tt, :ttung]]

(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

[juraj.masiar]

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!

Comment 59

[Tom Tung [:tt, :ttung]]

(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.

Comment 60

[Dominique Quatravaux]

Attachment: 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)).

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.

Comment 61

[Tom Tung [:tt, :ttung]]

(In reply to Dominique Quatravaux from comment #60)

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

Comment 62

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

(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

Comment 63

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

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?

Comment 64

[Jan Varga [:janv]]

Could be a similar problem as in bug 1517145.

Comment 65

[Dylan Hardison [:dylan] (he/him)]

The content of attachment 9055172 [details] has been deleted for the following reason:

Deleted by the request of ddurst

Comment 66

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

(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.

Comment 67

[Tom Tung [:tt, :ttung]]

(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

Comment 68

[Tom Tung [:tt, :ttung]]

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?

Comment 69

[Tom Tung [:tt, :ttung]]

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.)

Comment 70

[juraj.masiar]

Could be misplaced sqlite files cause of the "Error: The operation failed because the requested database object could not be found. For example, an object store did not exist but was being opened."?

Comment 71

[Graham Perrin]

(In reply to Andrew Sutherland [:asuth] (he/him) from comment #43)

… 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. …

bug 1493262 comment 11 re: thumbs.db

bug 1423917 comment 47 re: case insensitivity, elsewhere in 1423917 I see Thumbs.db but not thumbs.db – are both cases covered?

• https://docs.microsoft.com/windows/desktop/api/thumbcache/nn-thumbcache-ithumbnailcache#remarks exemplifies Thumbs.db
• https://docs.microsoft.com/azure/storage/files/storage-files-faq#afs-files-excluded exemplifies lowercase thumbs.db and if I recall correctly, I have seen at least one screenshot of Windows Explorer or File Explorer with thumbs.db

From bug 1423917 comment 85:

… let's just remove this constant and use case-insensitive comparison.

– but I can't tell whether the eventual fix compares in that way. (If I'm overlooking something: sorry.)

☑ bug 1423917 re: Desktop.ini and desktop.ini

☑ bug 1423917 comment 46 re: .desktop and .DS_Store

☐ Anything else?

Comment 72

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

(In reply to Graham Perrin from comment #71)

bug 1423917 comment 47 re: case insensitivity, elsewhere in 1423917 I see Thumbs.db but not thumbs.db – are both cases covered?

No. Thanks for pointing this out and providing the links (below)!

• https://docs.microsoft.com/windows/desktop/api/thumbcache/nn-thumbcache-ithumbnailcache#remarks exemplifies Thumbs.db
• https://docs.microsoft.com/azure/storage/files/storage-files-faq#afs-files-excluded exemplifies lowercase thumbs.db and if I recall correctly, I have seen at least one screenshot of Windows Explorer or File Explorer with thumbs.db

From bug 1423917 comment 85:

… let's just remove this constant and use case-insensitive comparison.

– but I can't tell whether the eventual fix compares in that way. (If I'm overlooking something: sorry.)

That was for desktop.ini and it is implemented that way, yeah.

:ttung, what do you think about making Thumbs.db comparison insensitive (so lower-case the constant and change the comparison to LowerCaseEqualsLiteral too)? QM_INIT_TELEMETRY_ERROR does still seem to be showing a lot of unexpected files.

Comment 73

[Tom Tung [:tt, :ttung]]

(In reply to Andrew Sutherland [:asuth] (he/him) from comment #72)

:ttung, what do you think about making Thumbs.db comparison insensitive (so lower-case the constant and change the comparison to LowerCaseEqualsLiteral too)? QM_INIT_TELEMETRY_ERROR does still seem to be showing a lot of unexpected files.

Sure, I will send a patch to you. Thank Graham, and Andrew for the notice! I didn't notice there is "thumbs.db".

BTW, I want to get these filenames by telemetry probes instead of waiting for reports, but still waiting for replies [1] because I'm not so sure if that data would be too sensitive and there is no category for tracking filenames.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1529016

Comment 74

[Tom Tung [:tt, :ttung]]

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

Could be misplaced sqlite files cause of the "Error: The operation failed because the requested database object could not be found. For example, an object store did not exist but was being opened."?

Yes, that's the error messages about not finding a database in the expected place. (Normally, SQLite databases should live inside the "idb" folder with a corresponding folder (the same name as the database file but ends with ".files"))

Comment 75

[Tom Tung [:tt, :ttung]]

Attachment: Bug 944918 - Allow thumbs.db in the storage directory;

Comment 76

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/be2f16510f29
Allow thumbs.db in the storage directory; r=asuth

Comment 77

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/be2f16510f29

Comment 78

[Tom Tung [:tt, :ttung]]

Comment on attachment 9069286 [details]
Bug 944918 - Allow thumbs.db in the storage directory;

Beta/Release Uplift Approval Request

• User impact if declined: If their storage directory contains "thumbs.db", the storage initialization would fail.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The patch only makes QuotaManager allow files with name "thumbs.db" in the storage directory and is verified with a unit test. So, this is not risky.
• String changes made/needed:

Comment 79

[voltron]

So the strategy to avoid this bug is to whitelist a number of different files that are "allowed" to be in the DB directory?

Forgive me if this is a stupid question but why should the IndexedDB engine care at all about files that are not part of the database? I mean shouldn't the engine code just read the files that it needs and ignore everything else there is in the directory?

The problem with the whitelisting approach is that there will always be new antivirus programs, OS features etc. that may add their temporary junk to whichever directory. And when that happens, things break and it can take a long time before a Firefox patch is released to fix that?

Comment 80

[Tom Tung [:tt, :ttung]]

(In reply to voltron from comment #79)

So the strategy to avoid this bug is to whitelist a number of different files that are "allowed" to be in the DB directory?

Forgive me if this is a stupid question but why should the IndexedDB engine care at all about files that are not part of the database? I mean shouldn't the engine code just read the files that it needs and ignore everything else there is in the directory?

The problem with the whitelisting approach is that there will always be new antivirus programs, OS features etc. that may add their temporary junk to whichever directory. And when that happens, things break and it can take a long time before a Firefox patch is released to fix that?

Thanks for providing opinion/suggestion! It's always good to have viewpoints in any direction. It would be great if you can point any existing files which don't appear on the list and break the IDB/storage.

We have been looking into this issue for a long while, but we don't have enough information on whether the current approach is suitable or not.

The advantage of the current approach (maintaining an allow list) is:

• Easy to catch problems because this approach is more strict.
• Making sure the usage of firefox storage be almost the same as the usage calculated by the OS (For instance, if there is a file created by some applications on the firefox storage directory, then general users might be confused when they check the usage from Firefox and OS) [1].

[1] Also, QuotaManager is responsible for managing quota and usage of Firefox. If a unexpected file which takes a lots of usage and it's ignored, that might be a potential issue for QuotaManager to manage the storage.

The disadvantage of it is just as what you mentioned:

• Comparatively easy to have an unexpected file and thus break the storage initialization/IDB

It is clear that there are not a few unexpected files on the storage/IDB directory and these files haven't been reported yet. I wanted to know the distribution of filenames for these unexpected files before making the next decision (bug 1529016). Like if most of them have the same filename, then we can keep the current approach. If these files are in different names, then we should consider ignoring these unexpected files in the storage directory instead of maintaining a list.

TBH, I don't have a strong opinion of taking the current approach, but maybe it's better to have more evidence (likes there are many unexpected files in different names created by antivirus/OS in the IDB/storage directories) before deciding to change.

Andrew and Jan, please correct me if I misunderstand anything and please elaborate more if you think there is anything unclear. Thanks!

Comment 81

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

Tom's understanding matches my own. Elaborating on our future plans, we are going to start erasing origins that are "corrupt" in the interest of being self-healing. The allow-list/allow-heuristics are useful to know what to ignore versus what merits erasing the origin.

I think the interesting question about features adding junk to directories is why/how the junk gets there. The options are:

1. Daemon process like A/V. I'd assume A/V would filter out any temporary files it creates, but even if they are transient, at least as long as the A/V cleans up after itself, it should not interfere with QuotaManager. If it is leaving garbage around, it does seem appropriate to clear the origin because no one else is going to clean it up.
2. Users browsing into the Quota Manager directories with file managers. It's probably worth noting that the entries we've added to our allow-list stem from the Windows and OS X file managers that date from when the OS's used "dumb" filesystems (or when they were using dumb filesystems, in the case of OS X dealing with FAT) that didn't support journaling or associated metadata. Going forward, I don't think we'd expect new types of metadata detritus to be created by Windows and OS X. For linux, well, we've added IsDotFile() to approve anything that starts with a period. That's been convention forever.

In the latter case, there's the question of why a user would be looking in the directory. Options would seem to be investigating breakage, investigating for privacy reasons, or investigating for disk usage purposes. In the breakage case, if we get confused and wipe the origin, it seems okay. Wiping if they're investigating privacy or disk usage does seem bad, but it's not clear why tools like that would be creating derived data-files everywhere in the tree.

The big thing for us is making sure that we have Telemetry data that tracks the rate of these clearings in general and specifically on an aggregate per-profile basis so that we can tell if these aren't one-off clearings but in fact evidence of a systemic problem. (Which is why bug 1529016 would be nice to get fixed.)

Comment 82

[Denis Lisov]

One unlikely but extremely frustrating scenario would arise if a user finds a database they want to keep more safe, makes a "backup" copy in the same directory - and exactly this action causes Firefox to remove both the original database and the "backup".

Comment 83

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

(In reply to Denis Lisov from comment #82)

One unlikely but extremely frustrating scenario would arise if a user finds a database they want to keep more safe, makes a "backup" copy in the same directory - and exactly this action causes Firefox to remove both the original database and the "backup".

I agree this would be unfortunate and really frustrating for the user in question. Noting that IndexedDB databases' schemas are highly specific to the version of JS code that created/used them at the time, so it's not clear that export of the databases would be useful[1]... I think our best hope for any use-case like this would be exporting the data to some weird newline-delimited JSON-ish format. (IndexedDB can store object graphs and things that JSON can't express, though, so it would be lossy.). Bug 1062613 was filed on doing that for localStorage/sessionStorage and one could certainly file a bug on that, but it's unlikely to be the highest priority.

1: In the sense that having the exported database isn't likely to be able to be usefully re-imported. I think it could be handy for analyzing what data a site is storing on your/its behalf. (Although most sinister uses of data would likely be exfiltrated and/or stored on less obviously associated origins/etc.)

Comment 84

[Julien Cristau [:jcristau]]

Comment on attachment 9069286 [details]
Bug 944918 - Allow thumbs.db in the storage directory;

I guess this won't hurt. I wish it were in its own bug though, as leave-open makes it painful to track changes.

Approved for 68.0b8.

Comment 85

[Tom Tung [:tt, :ttung]]

(In reply to Julien Cristau [:jcristau] from comment #84)

I guess this won't hurt. I wish it were in its own bug though, as leave-open makes it painful to track changes.

Sorry, will file a new bug to make it easier to be tracked next time.

Comment 86

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-beta/rev/5ec902740c06

Comment 87

[Julien Cristau [:jcristau]]

Comment on attachment 9069286 [details]
Bug 944918 - Allow thumbs.db in the storage directory;

clearing uplift flag to get this out of the uplift queries.

Comment 88

[gwarser]

Is this related?

PushService: stateChangeProcessEnqueue: Error transitioning state UnknownError PushService.jsm:144

IndexedDB UnknownErr: ActorsParent.cpp:581

IndexedDB UnknownErr: ActorsParent.cpp:581 2

IndexedDB UnknownErr: ActorsParent.cpp:581

Error: IndexedDB list() The operation failed for reasons unrelated to the database itself and not covered by any other error code. kinto-offline-client.js:579:19

IndexedDB UnknownErr: ActorsParent.cpp:581 Error: IndexedDB list() The operation failed for reasons unrelated to the database itself and not covered by any other error code. kinto-offline-client.js:579:19

IndexedDB UnknownErr: ActorsParent.cpp:581 Error: IndexedDB list() The operation failed for reasons unrelated to the database itself and not covered by any other error code. kinto-offline-client.js:579:19

IndexedDB UnknownErr: ActorsParent.cpp:581 Error: IndexedDB list() The operation failed for reasons unrelated to the database itself and not covered by any other error code. kinto-offline-client.js:579:19

IndexedDB UnknownErr: ActorsParent.cpp:581 Error: IndexedDB list() The operation failed for reasons unrelated to the database itself and not covered by any other error code. kinto-offline-client.js:579:19

IndexedDB UnknownErr: ActorsParent.cpp:581 Error: IndexedDB list() The operation failed for reasons unrelated to the database itself and not covered by any other error code. kinto-offline-client.js:579:19

IndexedDB UnknownErr: ActorsParent.cpp:581

From https://www.reddit.com/r/uBlockOrigin/comments/d33d4j/no_pages_loading_in_firefox_when_ublock_is_enabled/

Comment 89

[Tom Tung [:tt, :ttung]]

The unknown error is a general error when there is no better error code to define the failure.

So far, issues like:

• The errors that cause initialization failure
  For instance:
  • Unexpected files in the profile and thus cause initialization failures
  • Long filename issues on Windows

They are tracked in Bug 1482662, and Bug 1619893 for the errors during temporary storage initialization specifically.
The long filename issues should be fixed starting from Nightly 77.
Hopefully, we should get away from unknown files once we fixed bug 1621916, bug 1621920, and bug 1594075.

Note that another future plan is QuotaManager version 4 (bug 1593365). Hopefully, that would help us to avoid any corrupted storage in an origin to block all QuotaManager service.

• Error in structure cloned and thus cause entries in the sqlite database mismatching

We have made a refactoring for the indexedDB code that related to structure clone recently in Bug 1617170. We will see if the problem will still exist or not.

(In reply to gwarser from comment #88)
Sorry for the late reply, but do the problem still exist? If so, I will file another bug for that, and let's figure the problem out there.

I'm going to close this bug because this bug is a bit general. There are too many different issues inside this ticket. If I don't miss something, I think all issues here are tracked except the one in comment #88.

Please let me know if there is an issue in this bug and it is not tracked by another existing ticket. And we should focus on the cause of the issue on another ticket.

Comment 90

[Tom Tung [:tt, :ttung]]

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

(In reply to gwarser from comment #88)
Sorry for the late reply, but do the problem still exist? If so, I will file another bug for that, and let's figure the problem out there.

needinfo in case the issue is not tracked.