uBlock is not loading adminSettings at first run again

[anulman]

Prerequisites

• I verified that this is not a filter issue (MUST be reported at filter issue tracker)
• This is not a support issue or a question
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue
• The issue is not present after wholly disabling uBlock Origin ("uBO") in the browser
• I checked the documentation to understand that the issue I report is not a normal behavior

I tried to reproduce the issue when...

• uBO is the only extension
• uBO with default lists/settings
• using a new, unmodified browser profile

Description

If Chromium reloads after crashing, uBlock may not load adminSettings during its first run (see #1547). I notice that uBO caches lastVersion at script start; what if we deferred setting it until after the Promise.all instead?

A specific URL where the issue occurs

N/A

Steps to Reproduce

1. Set a custom filter list in /etc/chromium/policies/managed/ublock_policy.json
2. Load Chromium, then kill it before uBO finishes initializing
3. Load Chromium again, this time letting uBO finish initiaizing
4. uBO will not load the filters until Chromium next reboots

Expected behavior

I expected uBO to have restarted itself after it finished initializing the first time

Actual behavior

uBO did not restart itself, presumably because lastVersion had been set (making lastVersion !== '0.0.0')

uBlock Origin version

1.36.2

Browser name and version

Mighty (Chromium 91.0.4472.114)

Operating System and version

Ubuntu 18.04.4

[gorhill]

Please file an issue with Chromium devs for the issue of managed storage content not being served properly to extensions. The restart is merely a trickery to workaround an issue which is a browser issue -- the browser should properly return the content of the managed storage when an extension ask for it. I don't see trying to push further the trickery to be a good idea, assuming such approach can still technically be worked on.

[anulman]

Will do; they already have a bug about this.

Do you foresee any danger in moving vAPI.storage.set('lastVersion', foo) to after the Promise.all though?

[gorhill]

Do you foresee any danger

onVersionReady() is meant to execute code once needed sometimes when a version change, so moving out version saving would just create a potential issue affecting everybody just to address the other narrower potential issue here.

[anulman]

Thank you for the context!