Add proposal: Synchronous data at startup

[Rob--W]

This proposal offers a mechanism for extensions to specify values that are synchronously available when a content script or background script executes

This covers the use cases of #536, #703, #501, #747, among others.

[hackademix]

Nice to see some progress to fix this very ancient problem, thank you!

I'm quite happy with this proposal, but I must signal two major problems making it unsuitable as a replacement for the current XHR work-around (one is a blocker, the second is slightly less critical):

1. Blocker: without fixing request: allow to retrieve a tabId and documentId from the content script #469 there would be no way to tailor this configuration for certain tabs. Possible solution: adding filters such as includeTabIds[] / excludeTabIds[] to the ConfigStorageAreaSetOptions type.
2. Site-specific configuration would require a very large amount of useless data to be marshaled within this storage blob, making the understandable size limit a potentially serious constrain. Similarly to n.1, a possible solution would be adding filters such as matches[] / excludeMatches[] to the ConfigStorageAreaSetOptions type.

[carlosjeurissen]

@Rob--W Considering there seems to not be agreement on this PR yet, would it make sense to keep the issues open like #501? And potentially open a new issue to express support labels?

[xeenon]

@Rob--W Thanks for the proposal — this solves a real problem, but I strongly prefer a single storage.config area over the proposed two-area model.

Splitting into extensionConfig and contentScriptConfig introduces unnecessary complexity and developer confusion, with little benefit. The use cases are fully covered by a single area where:

• Extension contexts have read/write access.
• Content scripts have read-only access.

We already enforce content script access control for storage.session without needing separate namespaces, so duplicating the storage area purely for access restrictions feels unnecessary.

There’s also no precedent for changes in one namespace triggering events in another, and introducing that pattern (e.g., extensionConfig.set() firing contentScriptConfig.onChanged) adds avoidable complexity.

Also, I support keeping oldValue and newValue in the onChanged event — browsers should be able to detect changes without needing to deserialize values first (e.g., by comparing the binary representation of old and new values).

[xeenon]

Requesting changes based on my above comment.