Skip to content

InvalidStateError: A mutation operation was attempted on a database that did not allow mutations. #141

Closed
Closed
InvalidStateError: A mutation operation was attempted on a database that did not allow mutations.#141
Labels
Firefoxspecific to FirefoxbugSomething isn't workingfixedissue has been addressed

Description

@daspri
daspri
opened on Jul 22, 2018

Prerequisites

  • I verified that this is not a filter issue
  • This is not a support issue or a question
  • I performed a cursory search of the issue tracker to avoid opening a duplicate issue
    • Your issue may already be reported.
  • I tried to reproduce the issue when...
    • uBlock Origin is the only extension
    • uBlock Origin with default lists/settings
    • using a new, unmodified browser profile
  • I am running the latest version of uBlock Origin
  • I checked the documentation to understand that the issue I report is not a normal behavior

Description

Fails to update filters

A specific URL where the issue occurs

moz-extension://d879bf29-1bac-4212-8cbb-be53485d7ab0/dashboard.html

Steps to Reproduce

Open Firefox's "Browser Console" to see the error

  1. Go to Filter Lists
  2. Click 'Update Now'

Expected behavior:

Filters should update.

Actual behavior:

Filters do not update.

XHRGET https://raw.githubusercontent.com/gorhill/uBlock/master/assets/assets.json?_=212819
XHRGET https://publicsuffix.org/list/public_suffix_list.dat?_=212819
XHRGET https://raw.githubusercontent.com/uBlockOrigin/uAssets/master/filters/filters.txt?_=212819
XHRGET https://raw.githubusercontent.com/uBlockOrigin/uAssets/master/filters/badware.txt?_=212819
XHRGET https://raw.githubusercontent.com/uBlockOrigin/uAssets/master/filters/privacy.txt?_=212819
XHRGET https://raw.githubusercontent.com/uBlockOrigin/uAssets/master/filters/resource-abuse.txt?_=212819
XHRGET https://raw.githubusercontent.com/uBlockOrigin/uAssets/master/filters/unbreak.txt?_=212819
XHRGET https://easylist.to/easylist/easylist.txt?_=212819
15:53:46.412 [uBlock0CacheStorage] <unavailable>
vapi-cachestorage.js:94:9
genericErrorHandler
moz-extension://d879bf29-1bac-4212-8cbb-be53485d7ab0/js/vapi-cachestorage.js:94:9
XHRGET https://easylist.to/easylist/easyprivacy.txt?_=212819
[HTTP/2.0 200 OK 16ms]
15:53:46.993  InvalidStateError: A mutation operation was attempted on a database that did not allow mutations. vapi-cachestorage.js:230
putToDb/<
moz-extension://d879bf29-1bac-4212-8cbb-be53485d7ab0/js/vapi-cachestorage.js:230:17
getDb
moz-extension://d879bf29-1bac-4212-8cbb-be53485d7ab0/js/vapi-cachestorage.js:115:20
putToDb
moz-extension://d879bf29-1bac-4212-8cbb-be53485d7ab0/js/vapi-cachestorage.js:219:9
set
moz-extension://d879bf29-1bac-4212-8cbb-be53485d7ab0/js/vapi-cachestorage.js:77:9
onReady
moz-extension://d879bf29-1bac-4212-8cbb-be53485d7ab0/js/assets.js:533:9
getAssetCacheRegistry
moz-extension://d879bf29-1bac-4212-8cbb-be53485d7ab0/js/assets.js:426:9
assetCacheWrite
moz-extension://d879bf29-1bac-4212-8cbb-be53485d7ab0/js/assets.js:536:5
onRemoteContentLoaded
moz-extension://d879bf29-1bac-4212-8cbb-be53485d7ab0/js/assets.js:791:9
onLocalLoadSuccess
moz-extension://d879bf29-1bac-4212-8cbb-be53485d7ab0/js/assets.js:217:9
onLoadEvent
moz-extension://d879bf29-1bac-4212-8cbb-be53485d7ab0/js/assets.js:128:9

Your environment

  • uBlock Origin version:
  • Browser Name and version:
  • Operating System and version:

uBlock Origin v1.16.14
Firefox 61.0.1
Windows 7 x64

Activity

  2. daspri commented on Jul 23, 2018

    @daspri
    daspri
    on Jul 23, 2018
    Author

    118,292,480 bytes free on that firefox drive

    (browser.cache.disk.parent_directory is on a different drive with much more free space)

  3. gorhill commented on Jul 23, 2018

    @gorhill
    gorhill
    on Jul 23, 2018
    Member

    Not much I will be able to do, apparently Firefox errors when uBO tries to write to the indexedDB.

    If you search for firefox "A mutation operation was attempted on a database that did not allow mutations", you will find plenty of results. You may want to look into this. For example, did you set dom.indexedDB.enabled to false in about:config?

  4. daspri commented on Jul 23, 2018

    @daspri
    daspri
    on Jul 23, 2018
    Author

    No, that setting is still set "true".

    If I disable EasyList and restart firefox and Update Now, the update completes.

    If I then Purge Cache and Update Now, it fails with the same error but after a different list (unbreak).

    Briefly searching for this error mentions the dom.indexedDB.enabled setting (which I have set "true"), but results also suggest it can be caused by not waiting for an objectstore to be created before using it (async operations).

  5. uBlock-user
    added
    unable to reproducecannot reproduce the issue
    Firefoxspecific to Firefox
    on Jul 23, 2018

  6. uBlock-user commented on Jul 23, 2018

    @uBlock-user
    uBlock-user
    on Jul 23, 2018
    Member

    Can't reproduce. Filters updating as expected. Reset Firefox settings to default(including the ones you set in about:config) and try again.

  7. uBlock-user
    assigned
    daspri
    on Jul 23, 2018

  9. gorhill commented on Jul 23, 2018

    @gorhill
    gorhill
    on Jul 23, 2018
    Member

    According to Browser storage limits and eviction criteria, the global limit is 50% of free disk space, so ~60 MB in the current case.

    From this, there is a group limit, which if I understand correctly is that at most 20% of the global limit can by assigned to uBO, so 12 MB in the current case. So yes, it does seem like an issue with low disk space.

  11. gorhill commented on Jul 23, 2018

    @gorhill
    gorhill
    on Jul 23, 2018
    Member

    It's kind of a catastrophic error, the documentation said:

    The group limit is also called the "hard limit": it doesn't trigger origin eviction

    When this occurs, there is no fallback possible. This occurs deep in the code, when using Firefox API, and there might be no uBO UI available, aside the icon in the toolbar (assuming it has not been hidden by the user).

    At this point, if I am going to throw lot of coding work at this, I rather work on the feasibility of compressing the data so as to reduce the storage footprint -- well it would be nice if Firefox's implementation of indexedDB did this for everybody.

    At this point however, those suffering that sort of issue will have to free disk space. In the current case, ~120 MB is atypically low, regardless of uBO.

  13. gorhill commented on Jul 23, 2018

    @gorhill
    gorhill
    on Jul 23, 2018
    Member

    when I click on "Update now" animation is spinning indefinitely - a way to fix only this case?

    From what I see in the call stack above, this fails at the database level, not at the transaction level. There are error handlers at the transaction level. But it's a bit more complicated at the database level because the handlers at that level do not know about which callers need to be notified. It just means it's possible but not trivial to fix this. If I instead work on compressing (assuming feasability), this would possibly prevent uBO from failing (except in even more extreme cases of low disk space).

  15. 42 remaining items

  16. ghost added
    fixedissue has been addressed
    on Aug 14, 2018

  17. shellye5 commented on Aug 15, 2018

    @shellye5
    shellye5
    on Aug 15, 2018

    @gorhill sometimes filters take long to download with compression on any ideas on how to debug it?
    Are you enabling it soon?
    will this come to legacy too?

  18. Vangelis66 commented on Aug 29, 2018

    @Vangelis66
    Vangelis66
    on Aug 29, 2018

    ... Apologies if this isn't the proper place to post about my predicament, but I was directed to this issue via the Release Notes of the latest dev build...

    OS: Windows Vista SP2 32-bit
    Browser: Mozilla Firefox ESR 52.9.0 32-bit
    uBlockOrigin version: dev channel, v1.16.21b0 (WE)

    I was updated to the latest dev build from a previous dev build (from memory, must've been 1.16.17.7) which is now removed from the GitHub repo.

    I opened the dashboard and tried to manually update 3rd-party filters; the "clocks" at the far right of each list all started spinning but after a few (3-4) seconds all turned simultaneously into an orange triangle (with a white exclamation mark inside), then, after another 2-3 seconds, all went back into the "clock" state...

    This behaviour I had never witnessed previously, after some checks it looked as though my lists hadn't updated 😭 E.g., the "I don't care about cookies" list remained at v2.8.8, while I checked and v2.8.9 is already on line at its site...

    From looking closer at the release notes of 1.16.21b0, I saw

    A new advanced setting: cacheStorageCompression, default to true.
    When true, uBO will lz4-compress data before storing it in its cache storage in supported platforms.
    Currently, the only supported platform is Firefox/Firefox for Android.

    By launching Firefox Browser Console (CTRL+SHIFT+J), clearing everything inside it and starting a manual 3rd-party filter list update, the console is populated with many Error: LZ4BlockWASM: not initialized instances:

    brconsole

    I do hope they're meaningful to someone of you wonderful people...

    For now, my options to successfully update 3rd-party filter lists on my setup are tested to be:

    1. Access "advanced user" settings, toggle the new pref cacheStorageCompression to false, apply changes and then the update of lists will work...
    2. Downgrade to the latest version (1.16.20=1.16.18) of the stable channel, where cacheStorageCompression is either absent/not enabled by default.
    3. Downgrade to the latest legacy (XUL) version, 1.16.4.4, installable on 52.9.0 - sadly, it isn't backwards compatible with the WE versions, hence I'd have to reconfigure it from scratch...

    I understand that I don't have things on my side, as Vista has been EOL'd by MS and Fx 52.9.0 will be EOL'd by Mozilla in over a week's time... However, any insight as to what's the cause of this new issue will be highly appreciated...

    Many thanks in advance....

  21. gorhill
    added a commit that references this issue on Aug 29, 2018

    fix uBlockOrigin/uBlock-issues#141 (comment)

    3c187c6

  22. Vangelis66 commented on Aug 29, 2018

    @Vangelis66
    Vangelis66
    on Aug 29, 2018

    @gwarser

    Huge thanks for taking the time looking into my reported issue 👍

    Filters are not updated, something may be wrong with fallback js code.

    You may experience this #150

    I read all the discussion there, but I got the sense - I could be wrong, I know nothing about javascript language - that it did not pertain directly to my problem, despite being a FxESR 52.9.0 issue (but on Linux...); thanks all the same for the reference!

    WebAssembly.Instance
    Disabled in the Firefox 52 Extended Support Release (ESR).

    After switching on javascript.options.wasm

    For some obscure reason, I had already

    javascript.options.wasm;true
javascript.options.wasm_baselinejit;true

    inside about:config; I don't recall me toggling those specific prefs (but I may have simply forgotten, as the ESR cycle is many months old...), so perhaps this is possibly the work of an extension?

    BTW, this issue is resolved, you should create new one.

    ... Because of my marginal setup (EOL'd Windows OS, soon-to-be EOL'd Fx version, 32-bitness of OS (hence browser)), I wasn't really sure, to begin with, whether the new "compressing" code was meant to be compatible with my setup (or even tested in a non-Quantum Fx flavour and/or in a 32-bit browser build), so I opted to first post here, apologising in advance if inappropriate 😉 ...
    Once confirmed here this was a genuine new bug the devs were interested looking into, I'd have gladly created a new (separate) issue for it... But I was preempted by events:

    gorhill/uBlock@3c187c6

    @gorhill

    I just updated to the newest dev build, v1.16.21b1 and can confirm that filter lists update now works as it should with cacheStorageCompression=true; attaching Browser Console excerpt as proof:
    17_01_38.847 GET.txt

    A sterling job indeed, hugely valued! 👍 🥇

  23. Vangelis66 commented on Aug 29, 2018

    @Vangelis66
    Vangelis66
    on Aug 29, 2018

    @gwarser

    You can export your settings to file and import in new installation.

    Thanks for this tip, I'm sure I knew it already, but (originally) posting late at night and under some frustration doesn't help much in my growing age...

    Just to confirm, do the filter-list storage files the WE version saves inside ./profile/storage/default/* get somehow translated to the format of files the XUL version stores inside ./profile/extension-data/* when one downgrades from WE -> XUL and imports settings, as per your suggestion?

  25. resistor4u commented on Sep 4, 2018

    @resistor4u
    resistor4u
    on Sep 4, 2018

    I'm on 1.16.20 on Firefox 61.0.2 on Mac OS 10.11.6, and I'm unable to set cacheStorageCompression true in the Advanced settings - when I add and apply the settings, cacheStorageCompression disappears. Anyone else getting this?

  27. resistor4u commented on Sep 6, 2018

    @resistor4u
    resistor4u
    on Sep 6, 2018

    @gwarser if so, then perhaps the wiki documentation (https://github.com/gorhill/uBlock/wiki/Advanced-settings) should be changed? There, it says the feature is for "uBO 1.16.17b and above."

  28. mneunomne
    added 3 commits that reference this issue on Jul 16, 2026

    fix missing exception handler (uBlockOrigin/uBlock-issues#141)

    866ccc1

    added optional lz4 compression for cache storage (uBlockOrigin/uBlock…

    c011d96

    fix uBlockOrigin/uBlock-issues#141 (comment)

    7e9affc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Firefoxspecific to FirefoxbugSomething isn't workingfixedissue has been addressed

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions