tophf
commented
1 month ago Multiple developers strongly suggested that this should be implemented in MV3 many years ago, but the counter-argument from Chromium team was that there's no synchronous API in a service worker by design.
It may be easier to implement now that we saw heisenbugs in MV3 that Chromium team couldn't fix using the asynchronous methods and they're reworking Chromium's internals to make some parts of it synchronous: https://crbug.com/334940006
Conceptually, it's fine to extend this design because such a synchronous API is a practical necessity that demonstrably improves the extension platform by removing the boilerplate code and possible fragility due to race conditions e.g. in chrome.storage when the extension writes to it from multiple content scripts and its other open pages.
During TPAC 2024 (#659), we discussed the topic “there is not a good way to bootstrap state in the listener” in the context of background scripts. The outcome of the discussion is that we need an API that enables extension to store some state that persists across background restarts. Some limited amount of data may even be available across browser restarts. The exact details have to be figured out in a proposal.
Note: the request for state to be available at the top level has been requested before, in the context of content scripts, "globalParams" (#536). The request here is independent of that, and should not be confused with it.