release(runway): cherry-pick fix(snaps): Only trigger onActive and onInactive when client is unlocked (cp-13.7.0)
#37230
+65
−8
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
…`onInactive` when client is unlocked (cp-13.7.0) (#37222) <!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until the template has been completely filled out, and PR status checks have passed at least once. --> ## **Description** <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 2. What is the improvement/solution? --> This fixes an issue where Snaps may try to call APIs that are only available when the client is unlocked in the `onActive` handler. After this change, `onActive` is only called when the client is being unlocked, or when the client is already in the unlocked state and is opened. `onInactive` is only called when the client is in the unlocked state and closed, or when the client is being locked. [](https://codespaces.new/MetaMask/metamask-extension/pull/37222?quickstart=1) ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: Only trigger `onActive` and `onInactive` Snap lifecycle hooks when client is unlocked ## **Related issues** Fixes #37179. ## **Manual testing steps** 1. Go to this page... 2. 3. ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** - [ ] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Extension Coding Standards](https://github.com/MetaMask/metamask-extension/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [ ] I've completed the PR template to the best of my ability - [ ] I’ve included tests if applicable - [ ] I’ve documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [ ] I’ve applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-extension/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > Gate Snap lifecycle activation to the unlocked state and hook KeyringController lock/unlock to update Snap client activity. > > - **Snaps Init/Messenger**: > - Allow `SnapController:setClientActive` action and subscribe to `KeyringController:lock`/`unlock` in `SnapControllerInit`, calling `setClientActive(false|true)` accordingly. > - Extend init messenger types/permissions to include `SetClientActive` and `KeyringControllerUnlockEvent`. > - **MetaMask Controller**: > - In `isClientOpen` setter, call `SnapController:setClientActive` only if `KeyringController` is unlocked. > - **Tests**: > - Add tests verifying `setClientActive` is called on lock/unlock events and refactor test setup to accept a base messenger. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 468cadd. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->
Collaborator
✨ Files requiring CODEOWNER review ✨🫰 @MetaMask/core-platform (3 files, +56 -6)
|
Collaborator
📊 Page Load Benchmark ResultsCurrent Commit: 📄 Localhost MetaMask Test DappSamples: 100 Summary
📈 Detailed Results
Results generated automatically by MetaMask CI |
Collaborator
Builds ready [a69dbd5]
UI Startup Metrics (1291 ± 84 ms)
|
Contributor
|
CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes. |
davidrentc
approved these changes
Oct 27, 2025
gauthierpetetin
approved these changes
Oct 27, 2025
Collaborator
📊 Page Load Benchmark ResultsCurrent Commit: 📄 Localhost MetaMask Test DappSamples: 100 Summary
📈 Detailed Results
Results generated automatically by MetaMask CI |
Collaborator
Builds ready [d77d957]
UI Startup Metrics (1279 ± 85 ms)
|
metamaskbot
added
the
release-13.7.0
Collaborator
|
No release label on PR. Adding release label release-13.7.0 on PR, as PR was cherry-picked in branch 13.7.0. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
](https://codespaces.new/MetaMask/metamask-extension/pull/37222?quickstart=1){kind=link}
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.
onActiveandonInactivewhen client is unlocked (cp-13.7.0) (fix(snaps): Only triggeronActiveandonInactivewhen client is unlocked (cp-13.7.0) #37222)Description
This fixes an issue where Snaps may try to call APIs that are only
available when the client is unlocked in the
onActivehandler. Afterthis change,
onActiveis only called when the client is beingunlocked, or when the client is already in the unlocked state and is
opened.
onInactiveis only called when the client is in the unlockedstate and closed, or when the client is being locked.
Changelog
CHANGELOG entry: Only trigger
onActiveandonInactiveSnap lifecyclehooks when client is unlocked
Related issues
Fixes #37179.
Manual testing steps
Screenshots/Recordings
Before
After
Pre-merge author checklist
Docs and MetaMask
Extension Coding
Standards.
if applicable
guidelines).
Not required for external contributors.
Pre-merge reviewer checklist
app, test code being changed).
in the ticket it closes and includes the necessary testing evidence such
as recordings and or screenshots.
Note
Only notify Snaps of client active/inactive when the wallet is unlocked, wiring KeyringController lock/unlock events and adding tests.
KeyringController:lock/unlockevents toSnapController:setClientActiveviaSnapControllerInit.SnapControllerInitmessenger to allowSnapController:setClientActiveaction and subscribe to lock/unlock events.isClientOpensetter to callSnapController:setClientActiveonly ifKeyringControlleris unlocked.SnapController:setClientActiveis called withfalseon lock andtrueon unlock.Written by Cursor Bugbot for commit a69dbd5. This will update automatically on new commits. Configure here.
89eb2a2