Closed Bug 1522188 Opened 5 years ago Closed 2 years ago

storage.local IndexedDB database gets corrupted for some users

Categories

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

Product:
Core
Component:
Storage: IndexedDB
Version:
66 Branch
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox66 --- affected

People

(Reporter: jamaica_sven, Unassigned)

References

Details

Attachments

(3 files)

Firefox Nightly - 2019-01-23.jpg
193.79 KB, image/jpeg
Details
IndexedDB UnknownErr: ActorsParent.cpp:12482 6
5.18 KB, text/plain
Details
IndexedDB UnknownErr: ActorsParent.cpp:19997
11.05 KB, text/plain
Details

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

reference:
https://github.com/Drive4ik/simple-tab-groups/issues/316#event-2091946922

Affected is a Firefox Nightly (FFN) extension. But the cause is, based on its developer, an "unstable" FFN component.

The error happens during start of FFN.

Actual results:

The icon of that extension is replaced with a yellow triangle containing an exclamation sigh. And I cannot access the tab groups created with this extension.

Expected results:

Normally, the extension would load the proper icon. And I would have access to the tab groups created with this extension.

Please see as reference the discussion about this problem at the extension's page:
https://github.com/Drive4ik/simple-tab-groups/issues/316#event-2091946922

Please provide the steps to reproduce as already requested by the bug form.
That means that you describe step by step (!) how I can reproduce the problem with my Firefox installation.
Is this extension working in previous Firefox versions (release/beta) ?

Flags: needinfo?(jamaica_sven)

Hi, thanks.

This extension worked until 2 or 3 days ago.

Steps

  1. The extension "Simple Tab Groups" (STG) need to be installed on a previous version of FFN (start with v62) to see it functioning and to create tab groups.

  2. Allow FFN to update one version higher, up to this latest version, to see when that problem starts to occur.

  3. Start FFN.
    In the seconds after FFN has started, STG tries to load but fails shortly after and displays that yellow warnign triangle.

FFN FEATURE REQUEST: ROLL-BACK CLICK
It would be good, if FFN had a feature not only to update, but also to roll-back updates to become again a previous version. Example: with a clock I can instruct FFN v66 to roll-back to v65. There, with another click, I can roll-back from v65 to v64.

Such a feature would allow a much better user-side testing and therefore giving better detaislher ein situations like this.

Flags: needinfo?(jamaica_sven)

Seems like a bug in the extension ?

status-firefox66: --- → affected
Summary: Firefox Nightly v66 - Updated Forefox Component Crashes Plugin → Updated Firefox Component Crashes Plugin

I tried this:

  1. Installed https://addons.mozilla.org/en-US/firefox/addon/simple-tab-groups/ in Firefox 64
  2. opened 2 Tabs in Firefox64 with different URLs loaded
  3. clicked on the addon icon and selected "create new group" and this group had this 2 Tabs.
  4. opened "addon settings"->"Backup your simple Tab Groups" and saved the Tab group as .json
  5. closed Firefox64 and opened Firefox66 nightly from 2019-01-23 with a new profile
  6. installed addon again (see point 1) and loaded the saved backup
  7. backup was imported and seem to work like it should.

Did I something wrong ?

Flags: needinfo?(jamaica_sven)

I spoke with the developer, and he says, the error message points towards some Firefox files.

I had five groups, and in most of them over 50 tabs each.

I will now try to remove and re-install that extension, and report back here.

Flags: needinfo?(jamaica_sven)

Hi Sven,

Any updates on this issue? Did it re-occur after a fresh install?

Flags: needinfo?(jamaica_sven)

Hi. Yes, it still happens.

Flags: needinfo?(jamaica_sven)

I'm needinfo'ing :ddurst because the error mentioned in the GitHub issue is related to storage.

:ddurst, was there a change to WebExtensions storage that the add-on mentioned in this bug needs to update to account for?

Flags: needinfo?(ddurst)
See Also: → https://github.com/Drive4ik/simple-tab-groups/issues/316#event-2091946922

FYI: rpl has been looking into this, he's going to comment in that issue and here.

Flags: needinfo?(ddurst)

Goooood news! I am beginning to feel less desperate. :-)

Hi Hirnsausen,

as David mentioned in comment 9 I've been looking into this a bit during the past week,
unfortunately I'm still unable to reproduce the issue as described in https://github.com/Drive4ik/simple-tab-groups/issues/316#issue-402001458 and https://github.com/Drive4ik/simple-tab-groups/issues/283#issue-376849501
(locally I tried to recreate the following scenario: simple-tab-group installed, 5 groups created with ~10-15 tabs on each group), and so I need some help from you to get a better picture of the issue you are experiencing (so that I can find a way to trigger and investigate it in more detail).

Do you mind to also run some checks on the affected profile?

  • From a tab opened on "about:config"

    • what is the value of "extensions.webextensions.ExtensionStorageIDB.enabled"?
    • is there a pref named "extensions.webextensions.ExtensionStorageIDB.migrated.simple-tab-groups@drive4ik"?
      is its value set to true?

  • Open a tab on "https://firefox-storage-test.glitch.me/"

    • what are the results of the checks when you run the above test page on the affected profile?
      (this webpage runs some tests to verify that IndexedDB is working correctly, because the
      UnknownError mentioned in the Github issues linked above is usually due to IndexedDB being in
      broken state, usually because of unexpected files in the directory were Firefox stores
      all the IndexedDB databases, e.g. see Bug 944918, Bug 1423917 and Bug 1504535)

  • In the directory "<AFFECTED_PROFILE_PATH>/browser-extension-data/simple-tab-groups@drive4ik"

    • are there any of the following file names? "storage.js", "storage.js.migrated" or "storage.js.corrupted"

In comment 7 you mentioned that "it still happens", did it mean that you are able to reproduce the issue starting from a new clean profile? (or that you rolled back to the initial Firefox version and the old profile content and you tried again?)

If you are still able to reproduce the issue, could you look in the Browser Console if any error logged seems to be related to the extensions or IndexedDB right after you have reproduced it?

Flags: needinfo?(jamaica_sven)

Hi, thanks for your appreciated help and time you're spending.

Here is an update:

Things have changed. The change was caused by the latest updates on FFN and the way it handles sessions.

I did not encounter any new situations where the problem returned. There was no update on the side of the Plugin developer, it is still the same version. But there were, I believe, two new updates (or even more) to FFN in the same time frame.

I am still observing the plugin behavior over a longer time, before i want to comer to a conclusive statement, thta is why I did not yet report on this matter.

Is there any way, I can get a FFN-generated list of all installed plugins on my FFN with their latestt dates of updates? This might also help - if any plugins were updated during the dsame period, it might (maybe?) point towards a previous unintended interaction between plugins. I am not sure, though, as i do not know the plugin framework design of FFN.

Should I still go ahead with the Glitch testing you are mentioning? Anyhow, let me just do it.

extensions.webextensions.ExtensionStorageIDB.enabled = true
extensions.webextensions.ExtensionStorageIDB.migrated.simple-tab-groups@drive4ik = true

GlitchMe reports:

Storage is working. This is your first visit or all storage was automatically cleared.
Specific Subsystem Statuses:

LocalStorage
Good: Totally Working. (fullyOperational)
QuotaManager
Good: Totally Working. (fullyOperational)
IndexedDB
Good: Totally Working. (fullyOperational)
Cache API
Good: Totally Working. (fullyOperational)

Debug Info:

{
"v": 1,
"curVersion": 67,
"prevVersion": 0,
"ls": {},
"qm": {
"lastWorkedIn": 67
},
"idb": {
"persistentCreatedIn": 67,
"persistentLastOpenedIn": 67,
"clearDetectedIn": 0
},
"cache": {
"firstCacheCreatedIn": 67,
"unpaddedOpaqueCreatedIn": 0,
"paddedOpaqueCreatedIn": 67

Flags: needinfo?(jamaica_sven)
Product: Firefox → WebExtensions
Flags: needinfo?(lgreco)

Hi Hirnsausen,
thanks for looking into the details from Comment 11 and report back the results you got on your Firefox Nightly profile,
do you mind to also look if in the directory "<AFFECTED_PROFILE_PATH>/browser-extension-data/simple-tab-groups@drive4ik"
there are any of the following file names? "storage.js", "storage.js.migrated" or "storage.js.corrupted"?

Flags: needinfo?(lgreco) → needinfo?(jamaica_sven)

Yes, I would. But what is the exact path? I am using Windows 7. The above aliases don't give me enough information.

Flags: needinfo?(jamaica_sven)

You can find your profile's path by going to the about:profiles about page

Flags: needinfo?(jamaica_sven)

Thanks. :-)

I see two files there inside:

  • storage.js.migrated
  • storage.js-1.migrated
Flags: needinfo?(jamaica_sven)
Flags: needinfo?(lgreco)

Any updates?

(In reply to Hirnsausen from comment #17)

Any updates?

I took a look to a broken IndexedDB storage from another user of the simple-tab-groups extension that was experiencing the same issue:
I've been able to figure out what is making the storage.local.get() call to fail consistently on that database (some of the data added into IndexedDB is going to be stored in external files for efficiency reasons, and the file for the "groups" key had a different filename in the sqlite file and on disk), but we have not yet identified how the IndexedDB database has been able to enter that internally inconsistent state.

(I'm not clearing the needinfo assigned to me yet, as I'll get back to this once we've more details and a plan for fixing the underlying "IndexedDB corruption" issue).

Component: Untriaged → Storage
Flags: needinfo?(lgreco)
Summary: Updated Firefox Component Crashes Plugin → storage.local IndexedDB database gets corrupted for some users
Status: UNCONFIRMED → NEW
Ever confirmed: true

Some of our (Adblock Plus) users appear to be having problems with preferences being lost since Firefox 66 as well. But, we're having trouble reproducing the problem, or even really understanding what's happening.

Is there anything you'd like us to ask users who are experiencing data loss to check? Perhaps there's something that will give you a clue about what's going on?

(In reply to Dave Barker from comment #19)

Some of our (Adblock Plus) users appear to be having problems with preferences being lost since Firefox 66 as well. But, we're having trouble reproducing the problem, or even really understanding what's happening.

yeah, until now I also tried to reproduce this kind of issues a lot of times without any success. It is not yet clear how IndexedDB entered that state, but at least now I know which part of the IndexedDB storage data looks to be corrupted (thanks to that corrupted file I have been able to look into).

Is there anything you'd like us to ask users who are experiencing data loss to check? Perhaps there's something that will give you a clue about what's going on?

Yes, thanks a lot, that would be great! it would be quite helpful to know if they are all having the same underlying issue or different ones.

In Bug 944918 comment 63 I described in a bit more detail how I detected the reason for the "corrupted IndexedDB" state.

The steps described in the above comment may requires a user that is experienced enough with the command line, and so it is likely that some users may need more detailed instructions to be able to check it on their own (e.g. how to reach the Firefox profile, how to identify the right IndexedDB directory, how to install and use sqlite3 cli tool), but experienced users should be able to do the check as described in that comment.

Let me know if there is any detail of those steps that needs clarifications.

Flags: needinfo?(kzar)

Cool OK, I think we can help you there. It would be great for us to confirm this bug is the cause of our user's problems too!

I will figure out some instructions to send out to our affected users tomorrow and get back to you. I think it might be best if I request a copy of the affected user's extension data, that way I can perform the checks personally since some of the steps are pretty technical.

Flags: needinfo?(kzar)

AdBlock Plus: could be because since the last version of FFN each launch starts its own ID? I remember to have read some information about that new feature inside the Firefox Nightly NEW VERSION SUMMARY page. I believe (but I might be wrong), that this is the reason why ABP cannot load any preferences of any previous FFN usage.

Could ABP save those basic settings as bookmarks, using an "ABP_" in front of the naming..?

Same idea with the Simple Tab Groups as no extension is allowed to save anything on the local harddrives of the users. If the DB crashes and when having had exported all tabs of all groups into bookmarks (a feature it has), then it could rerstore all tabs from bookmarks but not into the previous groups. My idea is here, too, to use the following prefix for any bookmark name:
STB_(GroupName)_(TabName)

I will figure out some instructions to send out to our affected users tomorrow and get back to you.

We wrote up some instructions on Friday to send our to users who are experiencing the problem. The instructions aim to guide the user through the process of sending me their Adblock Plus extension data - turns out writing clear and jargon-free instructions is quite a pain! Anyway, our support team is going to start sending them out to affected users today / this week. I'm not sure how long it will be until I start actually receiving the extension data, but I'll keep you posted.

AdBlock Plus: could be because since the last version of FFN each launch starts its own ID? I remember to have read some information about that new feature inside the Firefox Nightly NEW VERSION SUMMARY page. I believe (but I might be wrong), that this is the reason why ABP cannot load any preferences of any previous FFN usage.

Interesting, do you have a link to where you read that so I can do a bit more research?

See Also: → 1517145

If this database is so incredibly fragile and easily corrupted, I could develop a small Windows program that creates a backup and also restores the DB from a backup. But I would need to know, where that DB is located, to create such a small gadget software.

Yes, thanks a lot, that would be great! it would be quite helpful to know if they are all having the same underlying issue or different ones.

In Bug 944918 comment 63 I described in a bit more detail how I detected the reason for the "corrupted IndexedDB" state.

This morning I received the first response from one of our users. The user reported that Adblock Plus was forgetting all whitelisted websites after a Firefox restart.

I followed your linked instructions, and sure enough I see exactly the same cause. His database references a file "134", but on the filesystem it's actually called "132".

Let me know if you want me to check anything else. I'll keep you posted if/when I receive more data from our users.

Flags: needinfo?(lgreco)

(In reply to Dave Barker from comment #25)

This morning I received the first response from one of our users. The user reported that Adblock Plus was forgetting all whitelisted websites after a Firefox restart.

I followed your linked instructions, and sure enough I see exactly the same cause. His database references a file "134", but on the filesystem it's actually called "132".

Thanks a lot, that is indeed very helpful. Let me know if you have been able to check some other of these corrupted storage files.

Let me know if you want me to check anything else. I'll keep you posted if/when I receive more data from our users.

Another detail that seems interesting (and suspicious) is that the user reported, as you mentioned above, that the issue has started happening after a Firefox restart.

do you mind to try to see if the affected user could be able to check in "about:crashes" if there is any crash report collected (submitted or unsubmitted) near the time and date of that Firefox restart?

(at least if they recall the day and an approximate time for that Firefox restart, or the first time they noticed the issue).

Flags: needinfo?(lgreco)

We received two more responses this morning, both seem to be caused by the same problem. The first had a database referencing "35" but the real file was called "36". The second's database referenced "271" but the real file was called "272".

I will check with them all about the crash reports now.

It's quite hard for our users to know exactly when the problem started, so figuring out the correct crash report (if any) requires a bit of guess work. That said, we have one potential report ID so far:

I'll keep you posted if/when I hear back from the others.

Ross on our team managed to reproduce the bug today and he shared his logs. As he pointed out, there's a couple of interesting entries in them:

IndexedDB UnknownErr: ActorsParent.cpp:13756
IndexedDB UnknownErr: ActorsParent.cpp:12090

(In reply to Dave Barker from comment #29)

Ross on our team managed to reproduce the bug today and he shared his logs. As he pointed out, there's a couple of interesting entries in them:

IndexedDB UnknownErr: ActorsParent.cpp:13756

This error looks to be coming from NormalTransaction::ActorDestroy.

IndexedDB UnknownErr: ActorsParent.cpp:12090

This one should be coming from InvalidateTransactions.

Hi :ttung, could you take a look if the above errors logged from the IndexedDB's ActorsParent.cpp could help us to identify what is triggering the data corruption?

Flags: needinfo?(shes050117)

Just in case this might be related...

Many users have reported issues with loading user settings, and a contributor identified that this was reproducible when setting browser.tabs.remote.autostart to false[1], and in general there seems to be issues arising with reading from browser.storage.local at launch when Firefox does not run in multi-process mode.[2]

[1] https://github.com/uBlockOrigin/uBlock-issues/issues/507#issuecomment-479536445
[2] https://www.reddit.com/r/uBlockOrigin/comments/ba6bxn/ublock_preventing_firefox_opening_sites_sometimes/ekhakzs

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

Jan, and Andrew, please correct me if I say anything not correct.

(In reply to Dave Barker from comment #29)

Ross on our team managed to reproduce the bug today and he shared his logs. As he pointed out, there's a couple of interesting entries in them:

IndexedDB UnknownErr: ActorsParent.cpp:13756

This happened when the mCommittedOrAborted hasn't been set so the transaction is still doing something on other thread or waiting for the next operation.

This means there might have an unexpected sequence of IPC messages so that the Transaction hasn't been committed or aborted.

This error looks to be coming from NormalTransaction::ActorDestroy.

IndexedDB UnknownErr: ActorsParent.cpp:12090

This one should be coming from InvalidateTransactions.

This means there still unfinished transactions for the invalidating database.

Flags: needinfo?(shes050117)

Ross on our team managed to reproduce the bug today...

Ross also confirmed that he doesn't think Firefox had crashed around the time when the bug showed up, so perhaps the database corruption isn't being caused by Firefox crashing?

Could it be, that someone developed a hostile extension that intentionally alters value inside the database? Just wondering, based on the examples given here about altered values.

What is the location of the Firefox DB? I want to develop a program that can copy and restore the DB. But I need its location and name.

(In reply to Hirnsausen from comment #34)

What is the location of the Firefox DB? I want to develop a program that can copy and restore the DB. But I need its location and name.

It should be at $Profile/storage/default/$origin/idb/$someDBName.sqlite

Note:

  • The location of your profile should be able to be found at about:profiles
  • If the idb is used by an add-on, the $origin should look like moz-extension-xxxxxx

No luck finding any more crash report IDs, but I did receive another corrupted storage directory from one of our users. Seems like the same problem, the database references a file "426" but the actual file is called "427".

(In reply to Dave Barker from comment #36)

No luck finding any more crash report IDs, but I did receive another corrupted storage directory from one of our users. Seems like the same problem, the database references a file "426" but the actual file is called "427".

This is the similar as what I saw in bug 944918

See Also: → 944918

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

This is the similar as what I saw in bug 944918

Yea, isn't this bug a duplicate of that one in fact?

(In reply to Dave Barker from comment #38)

Yea, isn't this bug a duplicate of that one in fact?

Could you help me check the id in the table object_store and id in the table file in the SQLite database?

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

Could you help me check the id in the table object_store and id in the table file in the SQLite database?

Sure, I can check the four corrupted databases I have. Here you go:

file table object_store table filesystem
134|1 1|0|storage-local-data| 132
35|1 1|0|storage-local-data| 36
271|1 1|0|storage-local-data| 272
426|1 1|0|storage-local-data| 427

(In reply to Dave Barker from comment #38)

Yea, isn't this bug a duplicate of that one in fact?

In my opinion they are not technically duplicates. They share the same error name ("UnknownError") and so we were initially wondering if they were the same bug, but with Bug 944918 comment 62 we determined that the two issues have different behaviors:

  • Bug 944918 was originally related to an "UnknownError" raised when opening the IndexedDB, due to unexpected files in the 'storage' directories, but no data was corrupted (it was just not accessible until the underlying issue was actually solved), it was basically an "initialization issue".

  • In this one the "UnknownError" is raised when trying to access a corrupted item, the IndexedDB database can be opened just fine (and so it doesn't look like an "initialization issue").

(In reply to Dave Barker from comment #40)

Thanks! I think from the perspective of the relationship between files and databases. It's more like bug 1515069 (Note that we just mitigated it from crashing rather than actually resolved that; right now it's bug 1519859).

file table object_store table filesystem
134|1 1|0|storage-local-data| 132
35|1 1|0|storage-local-data| 36
271|1 1|0|storage-local-data| 272
426|1 1|0|storage-local-data| 427

I received one more corrupted database this morning:

file table object_store table filesystem
348|1 1|0|storage-local-data| 349

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(ddurst)
Flags: needinfo?(ddurst)
Blocks: 1541370
Priority: -- → P2
Component: Storage → DOM: IndexedDB
Product: WebExtensions → Core

Received another corrupted database:

file table object_store table filesystem
754|1 1|0|storage-local-data| 756

Any update on a resolution for this?

Depends on: 1557289

(In reply to Shannon from comment #46)

Any update on a resolution for this?

Unfortunately, there is no effective resolution now, I need to investigate this again to get more information. The real cause seems to be somewhere before the place we found the database is corrupted. In the worst case, adding some assertion for diagnosing is probably needed.

Mitigation:
In Bug 1557289, I plan to remove existing problematic origin (which contains a corrupted database in IDB folder).

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

(In reply to Shannon from comment #46)

Any update on a resolution for this?

Unfortunately, there is no effective resolution now, I need to investigate this again to get more information. The real cause seems to be somewhere before the place we found the database is corrupted. In the worst case, adding some assertion for diagnosing is probably needed.

Mitigation:
In Bug 1557289, I plan to remove existing problematic origin (which contains a corrupted database in IDB folder).

Thanks for the details. Is there any additional information we can collect from our Adblock Plus users to assist in furthering your investigation?

(In reply to Shannon from comment #48)

Thanks for the details. Is there any additional information we can collect from our Adblock Plus users to assist in furthering your investigation?

Not for now, but I'll let you know if there is. Thanks!

(In reply to Shannon from comment #48)

Thanks for the details. Is there any additional information we can collect from our Adblock Plus users to assist in furthering your investigation?

Hey Shannon, I have two things want to confirm and check:

  • Could you help me to check if users got this warning message "Corrupt structured clone data detected in IndexedDB. Failing the database request. Bug 1519859 will address this problem." on their browser console while they found the issue? It's fired on the place where IDB catches the issue. I want to ensure at least they didn't crash.

  • It would be great if they can provide an STR for a clean profile. (I wouldn't expect that because it seems it's hard, but it would save me tons of time for finding the real cause)

Thanks!

Ok Sure thing! We'll work on some requests from our users and will let you know what we get.

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

(In reply to Shannon from comment #48)

Thanks for the details. Is there any additional information we can collect from our Adblock Plus users to assist in furthering your investigation?

Hey Shannon, I have two things want to confirm and check:

  • Could you help me to check if users got this warning message "Corrupt structured clone data detected in IndexedDB. Failing the database request. Bug 1519859 will address this problem." on their browser console while they found the issue? It's fired on the place where IDB catches the issue. I want to ensure at least they didn't crash.

  • It would be great if they can provide an STR for a clean profile. (I wouldn't expect that because it seems it's hard, but it would save me tons of time for finding the real cause)

Thanks!

Hey Tom!

Just an update on our side. Unfortunately, none of the users we've asked so far report seeing the warning message you mention in their web console :-/.

(In reply to Shannon from comment #52)

Hey Tom!

Just an update on our side. Unfortunately, none of the users we've asked so far report seeing the warning message you mention in their web console :-/.

Thanks for the information!

Then, I wonder how did they find out the issue. Is it "UnknownError" from IDB?

I had small incident on Nightly around 26 Jun, and captured few browser console logs. I'm not sure what to do with this, but maybe you will see some clues.

This happened after few restarts, because, I had problems updating uBO to 1.20.1beta4 - somehow Firefox did not want to update it - maybe something was already broken.

On first I noticed `TransactionInactiveError` in console:

```
22:10:06.202 [uBO] Admin settings ready 320 ms after launch console.js:26:40
22:10:06.861 [uBO] Backend storage for cache will be indexedDB console.js:26:40
22:10:06.861 [uBO] List selection ready 980 ms after launch console.js:26:40
22:10:07.860 [uBO] First fetch ready 1978 ms after launch console.js:26:40
22:10:07.861 [uBO] User settings ready 1979 ms after launch console.js:26:40
22:10:07.874 Unchecked lastError value: Error: TransactionInactiveError: A request was placed against a transaction which is currently not active, or which is finished. start.js:402
    onAdminSettingsRestored moz-extension://37511b5d-bb37-4294-a4f4-a4cf3aeaf04c/js/start.js:402
22:10:07.886 Error: TransactionInactiveError: A request was placed against a transaction which is currently not active, or which is finished. 3 ExtensionUtils.jsm
22:10:07.903 Error: InvalidStateError: A mutation operation was attempted on a database that did not allow mutations. 3 ExtensionUtils.jsm
22:10:08.179 [uBO] PSL ready 2297 ms after launch console.js:26:40
22:10:12.729 [uBO] Filter lists ready 6848 ms after launch console.js:26:40
22:10:12.734 [uBO] All ready 6852 ms after launch console.js:26:40
22:10:32.506 [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowUtils.removeSheetUsingURIString]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource://gre/modules/ExtensionCommon.jsm :: runSafeSyncWithoutClone :: line 65"  data: no] ExtensionCommon.jsm:65:12
    runSafeSyncWithoutClone resource://gre/modules/ExtensionCommon.jsm:65
    cleanup resource://gre/modules/ExtensionContent.jsm:353
    close resource://gre/modules/ExtensionContent.jsm:814
    destroyed resource://gre/modules/ExtensionContent.jsm:889
    observe resource://gre/modules/ExtensionContent.jsm:905
22:10:32.567 Promise resolved after context unloaded
content-script.js:10
    <anonymous> moz-extension://13987142-59ea-4ed1-84a6-407d674fa30a/content-script.js:10
22:10:32.569 TypeError: Argument 1 of PrecompiledScript.executeInGlobal is not an object. ExtensionContent.jsm:490:25
```

Some uBO settings reset:

- shortcuts are preserved
- whitelist reset
- my rules reset
- my filters preserved
- filter lists: custom lists section cleaned, "selectedFilterLists" in backup is preserved, externalLists is replaced by []
- settings reset

I did restore settings from backup and did not noticed any issues in extensions.

However later I noticed, that on every first Firefox start after computer restart browser console started logging more issues. First it was: `IndexedDB UnknownErr: ActorsParent.cpp:12482 6`

```
I had small incident on Nightly around 26 Jun, and captured few browser console logs. I'm not sure what to do with this, but maybe you will see some clues.

This happened after few restarts, because, I had problems updating uBO to 1.20.1beta4 - somehow Firefox did not want to update it - maybe something was already broken.

On first I noticed `TransactionInactiveError` in console:

```
22:10:06.202 [uBO] Admin settings ready 320 ms after launch console.js:26:40
22:10:06.861 [uBO] Backend storage for cache will be indexedDB console.js:26:40
22:10:06.861 [uBO] List selection ready 980 ms after launch console.js:26:40
22:10:07.860 [uBO] First fetch ready 1978 ms after launch console.js:26:40
22:10:07.861 [uBO] User settings ready 1979 ms after launch console.js:26:40
22:10:07.874 Unchecked lastError value: Error: TransactionInactiveError: A request was placed against a transaction which is currently not active, or which is finished. start.js:402
    onAdminSettingsRestored moz-extension://37511b5d-bb37-4294-a4f4-a4cf3aeaf04c/js/start.js:402
22:10:07.886 Error: TransactionInactiveError: A request was placed against a transaction which is currently not active, or which is finished. 3 ExtensionUtils.jsm
22:10:07.903 Error: InvalidStateError: A mutation operation was attempted on a database that did not allow mutations. 3 ExtensionUtils.jsm
22:10:08.179 [uBO] PSL ready 2297 ms after launch console.js:26:40
22:10:12.729 [uBO] Filter lists ready 6848 ms after launch console.js:26:40
22:10:12.734 [uBO] All ready 6852 ms after launch console.js:26:40
22:10:32.506 [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowUtils.removeSheetUsingURIString]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource://gre/modules/ExtensionCommon.jsm :: runSafeSyncWithoutClone :: line 65"  data: no] ExtensionCommon.jsm:65:12
    runSafeSyncWithoutClone resource://gre/modules/ExtensionCommon.jsm:65
    cleanup resource://gre/modules/ExtensionContent.jsm:353
    close resource://gre/modules/ExtensionContent.jsm:814
    destroyed resource://gre/modules/ExtensionContent.jsm:889
    observe resource://gre/modules/ExtensionContent.jsm:905
22:10:32.567 Promise resolved after context unloaded
content-script.js:10
    <anonymous> moz-extension://13987142-59ea-4ed1-84a6-407d674fa30a/content-script.js:10
22:10:32.569 TypeError: Argument 1 of PrecompiledScript.executeInGlobal is not an object. ExtensionContent.jsm:490:25
```

Some uBO settings reset:

- shortcuts are preserved
- whitelist reset
- my rules reset
- my filters preserved
- filter lists: custom lists section cleaned, "selectedFilterLists" in backup is preserved, externalLists is replaced by []
- settings reset

I did restore settings from backup and did not noticed any issues in extensions.

However later I noticed, that on every first Firefox start after computer restart browser console started logging more issues. First it was: `IndexedDB UnknownErr: ActorsParent.cpp:12482 6`

And then regularly started appearing: `IndexedDB UnknownErr: ActorsParent.cpp:19997` with lots and lots of telemetry warnings, slowing console to crawl 

```

I had small incident on Nightly around 26 Jun, and captured few browser console logs. I'm not sure what to do with this, but maybe you will see some clues.

This happened after few restarts, because, I had problems updating uBO to 1.20.1beta4 - somehow Firefox did not want to update it - maybe something was already broken.

On first I noticed TransactionInactiveError in console:

22:10:06.202 [uBO] Admin settings ready 320 ms after launch console.js:26:40
22:10:06.861 [uBO] Backend storage for cache will be indexedDB console.js:26:40
22:10:06.861 [uBO] List selection ready 980 ms after launch console.js:26:40
22:10:07.860 [uBO] First fetch ready 1978 ms after launch console.js:26:40
22:10:07.861 [uBO] User settings ready 1979 ms after launch console.js:26:40
22:10:07.874 Unchecked lastError value: Error: TransactionInactiveError: A request was placed against a transaction which is currently not active, or which is finished. start.js:402
    onAdminSettingsRestored moz-extension://37511b5d-bb37-4294-a4f4-a4cf3aeaf04c/js/start.js:402
22:10:07.886 Error: TransactionInactiveError: A request was placed against a transaction which is currently not active, or which is finished. 3 ExtensionUtils.jsm
22:10:07.903 Error: InvalidStateError: A mutation operation was attempted on a database that did not allow mutations. 3 ExtensionUtils.jsm
22:10:08.179 [uBO] PSL ready 2297 ms after launch console.js:26:40
22:10:12.729 [uBO] Filter lists ready 6848 ms after launch console.js:26:40
22:10:12.734 [uBO] All ready 6852 ms after launch console.js:26:40
22:10:32.506 [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowUtils.removeSheetUsingURIString]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource://gre/modules/ExtensionCommon.jsm :: runSafeSyncWithoutClone :: line 65"  data: no] ExtensionCommon.jsm:65:12
    runSafeSyncWithoutClone resource://gre/modules/ExtensionCommon.jsm:65
    cleanup resource://gre/modules/ExtensionContent.jsm:353
    close resource://gre/modules/ExtensionContent.jsm:814
    destroyed resource://gre/modules/ExtensionContent.jsm:889
    observe resource://gre/modules/ExtensionContent.jsm:905
22:10:32.567 Promise resolved after context unloaded
content-script.js:10
    <anonymous> moz-extension://13987142-59ea-4ed1-84a6-407d674fa30a/content-script.js:10
22:10:32.569 TypeError: Argument 1 of PrecompiledScript.executeInGlobal is not an object. ExtensionContent.jsm:490:25

Some uBO settings reset:

  • shortcuts are preserved
  • whitelist reset
  • my rules reset
  • my filters preserved
  • filter lists: custom lists section cleaned, "selectedFilterLists" in backup is preserved, externalLists is replaced by []
  • settings reset

I did restore settings from backup and did not noticed any issues in extensions.

However later I noticed, that on every first Firefox start after computer restart browser console started logging more issues. First it was: IndexedDB UnknownErr: ActorsParent.cpp:12482 6

And then regularly started appearing: IndexedDB UnknownErr: ActorsParent.cpp:19997 with lots and lots of telemetry warnings, slowing console to crawl.

Finally, I completely removed datareporting folder from profile, and errors stopped appearing.

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

(In reply to Shannon from comment #52)

Hey Tom!

Just an update on our side. Unfortunately, none of the users we've asked so far report seeing the warning message you mention in their web console :-/.

Thanks for the information!

Then, I wonder how did they find out the issue. Is it "UnknownError" from IDB?

When Adblock Plus starts, it detects that the extension storage was corrupted and displays a message to the user. For example, see this post on our forum https://adblockplus.org/forum/viewtopic.php?f=1&t=65609 .

(In reply to Dave Barker from comment #57)

(In reply to Tom Tung [:tt, :ttung] from comment #53)
When Adblock Plus starts, it detects that the extension storage was corrupted and displays a message to the user. For example, see this post on our forum https://adblockplus.org/forum/viewtopic.php?f=1&t=65609 .

I read the replies inside your forum. IIUC, the reason for corrupted extension storage is not confirmed. It could be multiple reasons. Could you ask them to run the website [1] to check if their storage system works as expected first? If the result is showing with red texts something red, it means their storage profile is broken. (The biggest reason is because of unexpected files, I will fix that in this Q). If all the stuff on [1] is green, then the issue is related to indexedDB.

The quick fix I can think of while we are working on a fix:

  • If they are okay with resetting their profile, then there are no issues.
  • If the color of the result in [1] is red and they don't want to lose all the bookmark, you could suggest them delete the folders under their $profile_dir/storage/ (It would be great if they can check the error message on the webconsole while going to the website)
  • If the color of the result in [1] is red and they don't want to lose all the bookmark, you could suggest they just delete all the folders with the prefix "moz-extension" under the folder of $profile_dir/storage/default/

Note: you can get the path for $profile_dir on "about:profiles" page
[1] https://firefox-storage-test.glitch.me/

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

I read the replies inside your forum. IIUC, the reason for corrupted extension storage is not confirmed. It could be multiple reasons. Could you ask them to run the website [1] to check if their storage system works as expected first? If the result is showing with red texts something red, it means their storage profile is broken. (The biggest reason is because of unexpected files, I will fix that in this Q). If all the stuff on [1] is green, then the issue is related to indexedDB.

Well, to be fair we did check those user's IndexedDB storage directories to see if they were corrupted in a way that's consistent with this issue. See my discussion with Luca from comment 20 onwards. I received 7 responses from our users, every one had a file name which didn't match the file table:

file table object_store table filesystem
134|1 1|0|storage-local-data| 132
35|1 1|0|storage-local-data| 36
271|1 1|0|storage-local-data| 272
426|1 1|0|storage-local-data| 427
348|1 1|0|storage-local-data| 349
754|1 1|0|storage-local-data| 756
22|1 1|0|storage-local-data| 23

(If you'd like me to check anything else with those storage directories just let me know.)

Could you ask them to run the website [1] to check if their storage system works as expected first?...

Sure, I can pass on those instructions no problem. Just checking though, is it still worth having the users try that website given what I said above?

(In reply to Dave Barker from comment #59)

Well, to be fair we did check those user's IndexedDB storage directories to see if they were corrupted in a way that's consistent with this issue. See my discussion with Luca from comment 20 onwards. I received 7 responses from our users, every one had a file name which didn't match the file table:

Ah, I somehow forgot your previous comments. Sorry about that :(

Sure, I can pass on those instructions no problem. Just checking though, is it still worth having the users try that website given what I said above?

Then, it's clear that their indexedDB databases are corrupted. So, it's not needed (I was thinking this might be another issue). Sorry for confusing again.

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

...Then, it's clear that their indexedDB databases are corrupted. So, it's not needed (I was thinking this might be another issue). Sorry for confusing again.

No problem, to be fair there's a lot of noise in the comments! Just let us know if we can check something, we're happy to help.

Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 23 votes.
:jjalkanen, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jjalkanen)

There has been no activity on this bug in three years but a mitigation and an error tag for following how often we see this issue were added by 1519859 . According to the data , it seems that the issue is not seen anymore.

The likely cause is that the database versions relevant for this issue have been deleted, replaced or recreated during the past few years. Let's reopen this, if an extension receives "Unknown error" on accessing a corrupted item.

Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(jjalkanen)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: