I think this is what #1240 entails for users. Privacy Badger takes a bit to initialize; the browser doesn't wait for Privacy Badger to initialize on browser start; if the browser starts opening pages right away (whether the homepage or previously open pages), it is likely Privacy Badger will miss at least some of what happens on those pages.

We could try speeding up Privacy Badger's initialization although we will probably always have some amount of lag before Privacy Badger is ready.

We could also update Privacy Badger's popup to somehow indicate that Privacy Badger wasn't available from the start of this page's loading, so this is only a partial report.

We could try speeding up Privacy Badger's initialization although we will probably always have some amount of lag before Privacy Badger is ready.

I totally agree with you

We could also update Privacy Badger's popup to somehow indicate that Privacy Badger wasn't available from the start of this page's loading, so this is only a partial report

I think this would be userfriendly to show info about the problem and maybe if Privacy Badger itself is not able to force a reload (e.g. if ffox is not alowing that) then the popup could include some sort of "please reload this tab" or show a reload button to assist. But this is maybe far away of a solution to handle this easily for users

Related Bugzilla issue: "Allow some addon functionality to load prior to any content loading".

So it seems that instead of having listeners get initialized without regard for storage initialization (which was the case before fde33ef), or having listeners get initialized after storage is initialized (fde33ef), which fixed the JS errors/bad request handling on browser startup but made the listeners "non-persistent" in Firefox and so led to missing (probably more) requests entirely on browser startup, we should explore initializing the listeners during initial synchronous execution (not in a callback) and either gracefully handle calling storage when it isn't yet ready (we miss processing some requests but maybe not as many as we miss now, at least in Firefox), or use async/Promises (would catch all requests but only in Firefox? what will happen in Chrome?).

Relevant discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=1501159

Edit: chrome (browser) API listeners should now be "persistent" again as of #2882.