Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR handles critical reliability issues when using webext-redux with Manifest V3 service workers, building on the improvements from v4.0.0.
Problems Solved
Problem: When a dormant service worker is awakened by a message, sendResponse() doesn't work reliably in Chrome's MV3 implementation. This caused proxy stores (in content scripts, popups, etc.) to fail during initialization when they tried to fetch the initial state from the background store.
Solution: Modified the state provider listener in wrapStore.js to use a dual-response approach:
Primary method: Broadcast the full state using browser.runtime.sendMessage() (reliable in MV3)
Fallback method: Still call sendResponse() for compatibility with smaller states
The proxy store's initialization logic already handles both message types, so it will use whichever arrives first and ignore duplicates.
Problem: If state patches (PATCH_STATE_TYPE messages) arrived before the initial full state (STATE_TYPE or FETCH_STATE_TYPE), they would be applied to an empty state object. This resulted in broken/partial state in proxy stores, causing UI bugs and undefined behavior.
Solution: Added a guard in Store.js to only apply patches after the store has received the full initial state at least once (tracked by the readyResolved flag that's already used for the ready() promise).
Testing

Impact