Ublock: suspendTabsUntilReady Keeps Resetting to false

[GuardianMajor]

When setting suspendTabsUntilReady to true under advanced settings, it resets back to false when the browser is next started.

This was working fine before but I can't pinpoint the exact moment it broke but it would have to be within the last few rc updates. I tried searching with as broadly as I could to see if it was discussed but found no hits, sorry if it has been discussed and I missed it.

Firefox 56.0 (x64) - clean profile
uB0 1.14.11rc10
Windows 10 Pro (x64) 1703

1. Open Advanced Settings

           assetFetchTimeout 30
  autoUpdateAssetFetchPeriod 120
            autoUpdatePeriod 7
       ignoreRedirectFilters false
   ignoreScriptInjectFilters false
manualUpdateAssetFetchPeriod 2000
               popupFontSize unset
       suspendTabsUntilReady false <--
       userResourcesLocation unset

1. Change to true
2. Apply Changes
3. Close the browser
4. Open the browser - setting is back to false

Is there anything I can check to see why this is happening? It was happening in my regular profile (barely 2 days old), so to rule out any conflicts or settings; I created a fresh profile, changed nothing, installed rc10 only and tried this and the same thing kept happening. The only thing that has changed since when it was working is that Firefox updated from 53.x to 56.x on Friday, that's it. Oh and of course the profile is freshly created so no .8 leftovers that might have made it work before, strictly WebExtension.

Beyond that, I can't think of anything and would appreciate anyone who might know what's going on or has a fix for it. TIA

[gorhill]

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

[GuardianMajor]

@gorhill I am aware of that bug, been following it and accordingly took steps on my end to mitigate it. I am not running incognito, so that wasn't the issue and while the browser does clear cache/cookies, I have a lot of protected cookies and fixed this issue with uB0 by simply protecting it's cookie set as f1378949-fc47-4cd4-be42-2d2d7f035902 at the time and that resolved the issue until they get around to doing a better job with this mess.

Upon checking, it seems that the extension id changed to f9cc5a91-bc82-41e8-84a4-87b58e86e816 at some point which wasn't protected, suggesting that's why the "fix" broke. I suspect that changed when the browser updated to 56 and the profile was recreated and uB0 was reinstalled, that changed the id.

So I reapplied my fix and just tested, and found that protecting the new cookie f9cc5a91-bc82-41e8-84a4-87b58e86e816 (for me) allowed me to retain the setting and it "fixes" the limitation for the time being. I was able to retain the true toggle across browser restart.

Even though you closed it before I could respond, thought this might help with some context as a workaround for now.

1. Load uB0 and note it's id for your system's installation (Note it will be different in each of the profiles you have uB0 installed, so if you want them in all profiles, you need to protect each and every instance).
2. Protect that cookie from being purged during the cleanup.
3. Settings will retain and remain.

As a follow-up question, do you think that perhaps saving those advanced settings in IndexedDB instead of the volatile localStorage could effectively make this problem moot? Just a thought to get you to mitigate on your end while Mozilla drags their feet on a real fix.