Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

State in background scripts, synchronously available across restarts #703

Open
Rob--W opened this issue Sep 28, 2024 · 1 comment
Open
Labels
needs-triage: chrome Chrome needs to assess this issue for the first time needs-triage: firefox Firefox needs to assess this issue for the first time supportive: safari Supportive from Safari

Comments

@Rob--W
Copy link
Member

Rob--W commented Sep 28, 2024

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.

@github-actions github-actions bot added needs-triage: chrome Chrome needs to assess this issue for the first time needs-triage: firefox Firefox needs to assess this issue for the first time needs-triage: safari Safari needs to assess this issue for the first time labels Sep 28, 2024
@tophf
Copy link

tophf commented Oct 5, 2024

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.

@xeenon xeenon added supportive: safari Supportive from Safari and removed needs-triage: safari Safari needs to assess this issue for the first time labels Oct 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-triage: chrome Chrome needs to assess this issue for the first time needs-triage: firefox Firefox needs to assess this issue for the first time supportive: safari Supportive from Safari
Projects
None yet
Development

No branches or pull requests

3 participants