release: 13.43.0 - #45055
Draft
metamaskbot wants to merge 164 commits into
Draft
Conversation
## Version Bump After Release This PR bumps the main branch version from 13.42.0 to 13.43.0 after cutting the release branch. ### Why this is needed: - **Nightly builds**: Each nightly build needs to be one minor version ahead of the current release candidate - **Version conflicts**: Prevents conflicts between nightlies and release candidates - **Platform alignment**: Maintains version alignment between MetaMask mobile and extension - **Update systems**: Ensures nightlies are accepted by app stores and browser update systems ### What changed: - Version bumped from `13.42.0` to `13.43.0` - Platform: `extension` - Files updated by `set-semvar-version.sh` script ### Next steps: This PR should be **manually reviewed and merged by the release manager** to maintain proper version flow. ### Related: - Release version: 13.42.0 - Release branch: release/13.42.0 - Platform: extension - Test mode: false --- *This PR was automatically created by the `create-platform-release-pr.sh` script.* Co-authored-by: metamaskbot <metamaskbot@users.noreply.github.com>
<!-- 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** upgrade bridge packages to latest versions <!-- 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? --> ## **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: null ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/SWAPS-4817 ## **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** - [x] 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). - [x] I've completed the PR template to the best of my ability - [x] I’ve included tests if applicable - [x] I’ve documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] 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] > **Medium Risk** > Dependency-only change, but bridge controllers sit on quote, swap, and cross-chain transaction paths—regressions would surface at runtime rather than in this diff. > > **Overview** > Bumps MetaMask bridge dependencies so the extension picks up the latest bridge package releases, with no application source changes in this PR. > > **`@metamask/bridge-controller`** goes from **77.5.0** to **^77.8.0**, and **`@metamask/bridge-status-controller`** from **74.3.0** to **^74.4.0**. Yarn resolutions still apply the existing **`@metamask/bridge-controller`** patch, now pinned to **77.8.0** (including an added resolution entry for **^77.7.0**). The lockfile refresh also updates transitive versions pulled in by those packages (e.g. **`@metamask/transaction-controller`** **^69.2.1** inside the bridge stack). > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit ee326a3. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: MetaMask Bot <metamaskbot@users.noreply.github.com> Co-authored-by: Maxime OUAIRY <maxime.ouairy-ext@consensys.net>
…ggregated balance cp-13.41.0 (#44796) <!-- CURSOR_AGENT_PR_BODY_BEGIN --> <!-- 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** The aggregated (portfolio) balance drops tokens whose human-readable balance is greater than or equal to `10^decimals` — e.g. a 54.06B TangYuan balance with 9 decimals on BNB Chain (#44786). **Root cause:** The `getAggregatedBalanceForAccount` selector in `@metamask/assets-controller` contains a `scaleToHumanIfRaw` heuristic that guesses whether a balance amount from `assetsBalance` state is in raw base units or human-readable form based on its magnitude: whenever the asset has `decimals` metadata and the amount is `>= 10^decimals`, the amount is assumed to be raw and divided by `10^decimals`. Since TangYuan's human-readable balance (54.06B) exceeds `10^9`, it gets wrongly divided down to ~54 tokens, its fiat contribution rounds to ~$0, and it effectively disappears from the aggregated total — while individual token rows (which do not apply this heuristic) show the correct fiat value. The heuristic is unnecessary: all `AssetsController` data sources (RPC, Accounts API, WebSocket) convert balances to human-readable form before writing them to state, so amounts in `assetsBalance` are always human-readable. Guessing raw vs. human by magnitude cannot be done correctly and corrupts legitimately large balances. **Solution (extension-repo only, no dependency changes):** In `aggregateGroupBalance` (`ui/selectors/assets.balance-utils.ts`), the state passed to `getAggregatedBalanceForAccount` is augmented with an empty `assetsInfo`. The heuristic only fires when `decimals` metadata is present, and metadata is otherwise only copied into the selector's returned `entries`, which this call site discards (only `totalBalanceInFiat` and `pricePercentChange1d` are consumed). Stripping the metadata therefore disables the rescaling with no other behavioral change to the totals. This single code point covers both `selectBalanceForAllWallets` and the balance-change selectors, which are the only consumers of the package's aggregation in the extension. Tests: - `ui/selectors/assets.balance-utils.aggregation.test.ts` — end-to-end regression test through the real (unmocked) package selector with a 54.06B-token / 9-decimals balance; it fails without the fix and passes with it. - `ui/selectors/assets.balance-utils.test.ts` — pins the augmentation: asserts the state handed to the aggregation selector has empty `assetsInfo` while `assetsBalance`/`assetsPrice`/`assetPreferences` pass through untouched. The proper fix should also be upstreamed to `MetaMask/core` (`packages/assets-controller/src/selectors/balance.ts`, where `scaleToHumanIfRaw` still exists on `main`); once a fixed version is adopted the augmentation can be removed. ## **Changelog** CHANGELOG entry: Fixed the aggregated account balance excluding tokens whose balance is very large relative to their decimals (e.g. 54B TangYuan with 9 decimals) ## **Related issues** Fixes: #44786 ## **Manual testing steps** 1. Run the extension with a wallet that holds a token whose human-readable balance is at least `10^decimals` — e.g. swap into TangYuan (9 decimals) on BNB Chain so the balance is in the billions of tokens. 2. Go to the homepage / asset list and note the fiat value shown on the token's own row. 3. Verify the aggregated account balance at the top of the wallet includes that token's fiat value (previously it was missing, making the total far too low). 4. Verify tokens with ordinary balances (e.g. POSI with 18 decimals) are still priced correctly and the total matches the sum of the individual token rows. ## **Screenshots/Recordings** ### **Before** See issue - `TangYuan` was not added to aggregate calculation ### **After** <img width="524" height="624" alt="Screenshot 2026-07-23 at 20 38 24" src="https://github.com/user-attachments/assets/ba84a9a4-e839-46ed-aac9-e2b27558ffb4" /> ## **Pre-merge author checklist** - [x] 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). - [x] I've completed the PR template to the best of my ability - [x] I’ve included tests if applicable - [x] I’ve documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] 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_AGENT_PR_BODY_END --> <div><a href="https://cursor.com/agents/bc-c121dd8a-01f5-43f9-a8a8-b56931f842b8"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-web-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-web-light.png"><img alt="Open in Web" width="114" height="28" src="https://cursor.com/assets/images/open-in-web-dark.png"></picture></a> <a href="https://cursor.com/background-agent?bcId=bc-c121dd8a-01f5-43f9-a8a8-b56931f842b8"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-cursor-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-cursor-light.png"><img alt="Open in Cursor" width="131" height="28" src="https://cursor.com/assets/images/open-in-cursor-dark.png"></picture></a> </div> --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com>
## **Description** Update cla.yml with more Cursor names. ## **Changelog** CHANGELOG entry: null <!--## **Related issues** ## **Manual testing steps** ## **Screenshots/Recordings** ## **Pre-merge author checklist** ## **Pre-merge reviewer checklist**--> <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Single CI configuration change with no runtime, auth, or data-handling impact. > > **Overview** > Updates the **CLA Signature Bot** workflow allowlist so additional Cursor-related GitHub actors are exempt from CLA checks. > > The `allowlist` in `.github/workflows/cla.yml` now includes **`cursorbot`** and **`cursor[bot]`** alongside the existing **`cursoragent`** entry, so automated Cursor PRs are treated like other trusted bots (e.g. Dependabot, Copilot). > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit aabb4fa. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
## **Description** Flips `MM_PURE_BLACK_PREVIEW` from `false` to `true` in `builds.yml` and `.metamaskrc.dist` so that the pure black (OLED) dark mode is enabled for all users in the build. This gives us a week of testing in 13.42.x before the feature ships permanently in 13.43.0. ## **Changelog** CHANGELOG entry: Enabled pure black (OLED) dark mode for users with dark theme active. ## **Related issues** Fixes: TMCU-1166 ## **Manual testing steps** 1. Run `yarn start` (no `.metamaskrc` change needed — the flag is now `true` by default in the build). 2. Enable dark theme in Settings → Preferences and display → Theme → Dark. 3. Confirm pure black (`#000000`) background is applied throughout the extension. 4. Toggle back to light or system theme and confirm no visual regressions. 5. Check the popup flash (`popup-init.html`), side menu, modals, and popovers for correct elevation surfaces. ## **Screenshots/Recordings** ### **Before** <!-- Pure black was opt-in via .metamaskrc --> ### **After** <!-- Pure black enabled for all dark mode users --> ## **Pre-merge author checklist** - [x] 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). - [x] I've completed the PR template to the best of my ability - [x] 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.
## **Description** Fixes the background flash sequence system-dark users see when opening the extension in pure black mode. There are three moments where a background color is visible before the full UI renders, and they all need to agree: 1. **\`popup-init.html\`** — a static redirect page with no JavaScript. Uses \`prefers-color-scheme: dark\` to set an initial background while it redirects to \`popup.html\`. Changed from \`#121314\` to \`#000000\`. 2. **\`:root\` in \`base-styles.scss\`** — the \`light-dark()\` fallback that fires immediately on \`popup.html\` parse, before JavaScript has applied \`data-theme\` or \`data-pure-black\` attributes. Because no data attributes exist at this point, a CSS selector cannot be used — brand color tokens are the only option. Changed from \`--brand-colors-grey-grey1000\` to \`--brand-colors-black\`. 3. **\`html[data-theme='dark'][data-pure-black='true']\`** (already in \`base-styles.scss\`) — applies after JavaScript sets theme attributes. Unchanged; this continues to own the post-JS state via the semantic token. Without both changes, fixing only \`popup-init.html\` would swap one mismatch for another: \`#000000\` init flash → \`grey-grey1000\` root frame → \`#000000\` themed. > **Note:** Both changes affect all system-dark users, not just pure black users, since neither \`prefers-color-scheme\` nor \`:root\` can read MetaMask theme settings. They should not be merged until the \`MM_PURE_BLACK_PREVIEW\` feature flag ships in 13.43.0. ## **Changelog** CHANGELOG entry: null ## **Related issues** Fixes: TMCU-1158 ## **Manual testing steps** 1. Enable \`MM_PURE_BLACK_PREVIEW=true\` in \`.metamaskrc\` and run \`yarn start\`. 2. Enable dark theme in Settings → Preferences and display → Theme → Dark. 3. Click the extension icon — the flash from \`popup-init.html\`, the \`:root\` frame on \`popup.html\`, and the final themed background should all be pure black with no visible transition. 4. Toggle to light theme and verify the white background still appears at each stage. ## **Screenshots/Recordings** ### **Before** Flash sequence: #121314 (popup-init) → #24272A (root) → #000000 (themed) https://github.com/user-attachments/assets/27c3b95a-c36d-4e31-8b2a-e60ebe1bf6db ### **After** Flash sequence: #000000 → #000000 → #000000 — seamless https://github.com/user-attachments/assets/0e5d7183-b1bc-42f1-b161-623b99d9b7ef ## **Pre-merge author checklist** - [x] 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). - [x] I've completed the PR template to the best of my ability - [x] 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.
<!-- 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? --> RC Slack was gated on full main `success`, so “Builds ready” on the PR could exist while Slack never posted (e.g. 13.42.0). Slack now posts when `Publish prerelease` succeeds on a release main run, even if other jobs failed. ## **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: null ## **Related issues** Fixes: [Slack thread](https://consensys.slack.com/archives/C0BJLRDCADT/p1784847360954639?thread_ts=1784847158.875339&cid=C0BJLRDCADT) ## **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] > **Low Risk** > CI notification gating only; no runtime, auth, or release artifact logic changes beyond when Slack is sent. > > **Overview** > **RC Slack notifications** now fire when release **Main** finishes with **Builds ready** (`Publish prerelease / Publish prerelease` succeeded), instead of requiring the entire **Main** workflow to be green. > > The `workflow_run` trigger still runs on completed **Main** for `release/*`, but the job `if` accepts **success** or **failure** conclusions. A new gate step uses `gh run view` (with **`actions: read`**) to require the inner **Publish prerelease** job succeeded and an open **release → stable** PR before posting. Comments in `rc-slack-notify.yml` and `slack-rc-notification.mts` describe this behavior. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 35b5992. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
<!-- 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** Adds an E2E metrics test that asserts Wallet Setup Started (historically Wallet Setup Selected) is sent with the expected onboarding properties when a user creates a wallet with SRP and opts into MetaMetrics. <!-- 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? --> ## **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: null ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/MMQA-2060 ## **Manual testing steps** CI should pass Use the below command to execute the test locally yarn start:test yarn test:e2e:single test/e2e/tests/metrics/wallet-setup-started.spec.ts --browser=chrome ## **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] > **Low Risk** > Test-only change with no production or analytics implementation modifications. > > **Overview** > Adds E2E coverage for the **Wallet Setup Started** Segment track event during onboarding. > > The new `wallet-setup-started.spec.ts` runs the create-wallet-with-SRP flow with MetaMetrics opted in, mocks Segment via the shared metrics mock helper, and asserts exactly one track event with expected properties (`account_type`, `category`, `locale`, `chain_id`, `environment_type`). > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 8dfb722. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
Migrates Core UX-owned ButtonSecondary usages to the MMDS Button
component with variant={ButtonVariant.Secondary}. This removes
deprecated ButtonSecondary / ButtonSecondarySize imports from the
targeted owned files and updates the affected network, token, NFT
import, and import-account flows to use the current design system API.
## **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?
-->
## **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: null
## **Related issues**
Fixes:
## **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]
> **Low Risk**
> Presentational swap only; handlers and flows are unchanged, with minor
visual/DOM differences from the new design system button.
>
> **Overview**
> Replaces deprecated **component-library** `ButtonSecondary` with
**`@metamask/design-system-react`** `Button` using
`variant={ButtonVariant.Secondary}` in Core UX flows: native-token scam
warning modals (`token-cell`, `token-list-item`), import-account cancel
(`bottom-buttons`), import-NFT cancel, and the network list **Add a
custom network** action (including `IconName` from the design system).
>
> Prop mapping is consistent: `block` → `isFullWidth`,
`ButtonSecondarySize` → `ButtonSize`. **Primary** actions still use
`ButtonPrimary` where unchanged. Jest snapshots were updated for the new
MMDS button DOM (Tailwind-based classes and icon markup).
>
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
cf52226. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
…d transactions from activity page cp-13.41.0 (#44780) <!-- 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? --> Fixes Monad swap activity details showing a network fee amount instead of `Paid by MetaMask` for gas-sponsored swaps. This PR reuses the existing gas sponsorship display logic and applies it to the new Activity Details fee rows. When a local transaction is marked as gas-sponsored, Activity Details now renders the network fee as `Paid by MetaMask` instead of showing a calculated fee. Also adds unit tests for the sponsorship logic and fee row rendering. ## **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: Fixed sponsored network fee transfer to show the `Paid by MetaMask` label in activity page ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/WPN-1713 ## **Manual testing steps** 1. Perform a MON to USDC swap on Monad. 2. Open the Activity tab. 3. Click the completed swap transaction. 4. Verify the transaction details show: - Network fee - Paid by MetaMask 5. Open the same swap from the token details activity list 6. Verify the token details transaction view also shows - Network fee - Paid by MetaMask 10. As a regression check, open a normal non-sponsored transaction 11. Verify normal transactions still show the calculated network fee amount instead of `Paid by MetaMask` 12. As another regression check, verify rejected transactions do not show `Paid by MetaMask` ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> <img width="831" height="813" alt="625474154-06befb51-1ed3-48be-8a88-a91cbd295c6a" src="https://github.com/user-attachments/assets/da34bba1-ba3c-47c1-98f0-432494f4a094" /> ### **After** <!-- [screenshots/recordings] --> <img width="1009" height="1283" alt="Screenshot From 2026-07-23 15-51-51" src="https://github.com/user-attachments/assets/9b921be1-41c5-4906-94a7-1376c9f8b0a5" /> ## **Pre-merge author checklist** - [X] 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). - [X] I've completed the PR template to the best of my ability - [X] I’ve included tests if applicable - [X] I’ve documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [X] 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** - [X] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [X] 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] > **Low Risk** > Display-only activity fee labeling with shared sponsorship helper; covered by unit tests and no payment or signing logic changes. > > **Overview** > Gas-sponsored swaps (e.g. Monad) were showing a calculated **network fee** in Activity Details instead of **Paid by MetaMask**. This change wires the same sponsorship rules used on the legacy transaction breakdown into the activity fee pipeline. > > Local activity items now attach a `gas-fee-sponsored` fee marker when `isGasFeeSponsored` applies (with hardware wallets, failed-without-receipt, revoke delegation, and rejected txs excluded). When API-enriched activity replaces the local row, `mergeActivityItemSponsoredFees` keeps that marker and drops the API’s base network fee. **FeesRows** renders the sponsored type as **Paid by MetaMask** via `SuccessPill`. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 1800b9b. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
…lected a nonevm network (#44706) ## **Description** When a hardware-wallet account group is selected and the user switches to a Non-EVM network, MetaMask silently changes `selectedAccount` to a Snap account. Gas sponsorship / gasless eligibility still used `isHardwareWallet`, which only checks that globally selected account, so the HW account was mis-classified as eligible and “Gas sponsored” UI could incorrectly appear. This PR adds `useIsHardwareWalletAccount`, which prefers an explicit address (e.g. confirmation `txParams.from`), then the selected group’s EVM account, then the global selection. Gas sponsorship and gasless hooks (`useIsNetworkGasSponsored`, `useIsGaslessSupported`, `useGaslessSupportedSmartTransactions`) now use that helper so HW accounts stay excluded even when a Non-EVM network is selected. ## **Changelog** CHANGELOG entry: Fixed gas sponsorship incorrectly appearing for hardware wallet accounts when a Non-EVM network is selected ## **Related issues** Fixes: [MUL-2011](https://consensyssoftware.atlassian.net/browse/MUL-2011?atlOrigin=eyJpIjoiZjE0NDgwZjVlYWM4NDE2NWJmZmFhMGFiYjNjY2QzNzMiLCJwIjoiaiJ9) ## **Manual testing steps** 1. Import/connect a Ledger, Trezor, or QR hardware wallet account and select that account group. 2. Switch the selected network to a Non-EVM network (e.g. Solana). 3. Navigate to a gas-sponsored EVM network flow (e.g. send / confirmation on Monad or another sponsored chain available in your build). 4. Verify the “Gas sponsored” / gasless UI is **not** shown for the hardware wallet account. 5. Switch back to an HD/imported EOA on the same sponsored network and verify gas sponsorship still appears when expected. 6. With HW selected on an EVM network (no Non-EVM switch), confirm sponsorship remains hidden as before. ## **Screenshots/Recordings** ### **Before** https://github.com/user-attachments/assets/36df87eb-942f-41a3-8104-e094aa322795 ### **After** https://github.com/user-attachments/assets/e796243a-e042-411c-b3a6-f821ef92e5ac <!-- ## **Screenshots/Recordings** --> ## **Pre-merge author checklist** - [x] 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). - [x] I've completed the PR template to the best of my ability - [x] I’ve included tests if applicable - [x] I’ve documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] 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. [MUL-2011]: https://consensyssoftware.atlassian.net/browse/MUL-2011?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Changes eligibility logic for gas sponsorship and gasless confirmations across multiple hooks; behavior is narrower (more HW exclusions) but affects user-visible transaction flows. > > **Overview** > Fixes **gas sponsored** and **gasless** UI incorrectly treating Ledger/Trezor sends as eligible when the user picks a Non-EVM network while a hardware account group is still selected—`selectedAccount` can become a Snap account even though the EVM `from` address is still hardware. > > Introduces **`useIsHardwareWalletAccount`**, which resolves hardware status in order: optional address (e.g. confirmation `txParams.from`), the selected account group’s EVM EOA, then the legacy `isHardwareWallet` global selection. > > **`useIsNetworkGasSponsored`**, **`useIsGaslessSupported`**, and **`useGaslessSupportedSmartTransactions`** now use this hook instead of `isHardwareWallet` alone; confirmation paths pass **`transactionMeta?.txParams?.from`** so eligibility follows the signing account. Unit tests cover the new hook and the Non-EVM / HW `from` scenario. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 60d0ff7. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
The Google sign-in button in the onboarding flow and security settings (SRP reveal list) was using the legacy 4-segment flat Google `G` icon (`google.svg`). Google has updated their brand icon to a new gradient `G` logo. <!-- 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. --> JIRA LINK : https://consensyssoftware.atlassian.net/browse/TO-936 ## **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? --> - The existing `google.svg` used the outdated flat multi-colour Google `G` icon - The `srp-reveal-list__social-icon` CSS class was referenced in `reveal-srp-list.tsx` but was never defined in `index.scss`, causing the Google icon to render at 0×0 px (invisible) ### Solution - Replaced `app/images/google.svg` with Google's updated gradient `G` logo (no background, no border — logo only, compliant with Google branding guidelines for use alongside button text) - Tightened the SVG `viewBox` to crop padding, set explicit `width="20" height="20"` so the intrinsic size is always reliable regardless of CSS context - Added the missing `&__social-icon { width: 24px; height: 24px; }` rule to `reveal-srp-list/index.scss` to fix the invisible icon in the security settings page ## **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: Updated Google sign-in button icon to the new Google gradient `G` logo; fixed invisible Google icon on the Secret Recovery Phrase security settings page. ## **Related issues** ## **Manual testing steps** 1. Run the extension (`yarn start`) 2. Go to the onboarding welcome screen 3. Verify the Google button shows the new gradient `G` icon (no circle border, no white/dark background) 4. Verify the icon looks correct in both light and dark themes 5. Navigate to **Settings → Security & Privacy → Secret Recovery Phrase** 6. Verify the Google icon is now visible next to the social login email address (previously 0×0 and invisible) ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> <img width="519" height="174" alt="Screenshot 2026-07-23 at 1 42 46 PM" src="https://github.com/user-attachments/assets/83ecb61a-ebdf-485d-9ed3-344a54012c50" /> <img width="446" height="272" alt="Screenshot 2026-07-23 at 1 42 50 PM" src="https://github.com/user-attachments/assets/ee5d76b4-ef28-4211-9ecb-fef3d637045f" /> ### **After** <!-- [screenshots/recordings] --> <img width="470" height="649" alt="Screenshot 2026-07-23 at 1 31 36 PM" src="https://github.com/user-attachments/assets/9f6702f7-5cda-4226-bc5d-34832d626e1a" /> <img width="595" height="768" alt="Screenshot 2026-07-23 at 1 31 43 PM" src="https://github.com/user-attachments/assets/6fd53b63-2728-4b86-a725-1049b6f19819" /> <img width="737" height="822" alt="Screenshot 2026-07-23 at 1 31 54 PM" src="https://github.com/user-attachments/assets/ccec6f45-0864-4fff-9679-45be233ffca6" /> <img width="620" height="800" alt="Screenshot 2026-07-23 at 1 32 01 PM" src="https://github.com/user-attachments/assets/ae2f864b-2b42-4ecd-b2b0-3ee68df330ba" /> <img width="857" height="305" alt="Screenshot 2026-07-23 at 1 32 32 PM" src="https://github.com/user-attachments/assets/cec5aee6-fbb1-4221-b325-d4c523ccbd8f" /> <img width="886" height="313" alt="Screenshot 2026-07-23 at 1 32 42 PM" src="https://github.com/user-attachments/assets/e490d72e-8f7d-436b-aa32-141d19fb965a" /> ## **Pre-merge author checklist** - [x] 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). - [x] I've completed the PR template to the best of my ability - [x] I’ve included tests if applicable - [ ] I’ve documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] 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** - [x] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [x] 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] > **Low Risk** > Visual-only asset and stylesheet changes with no auth or business-logic impact. > > **Overview** > Updates the shared **`images/google.svg`** asset from the legacy flat four-color **G** to Google’s newer gradient **G** (cropped viewBox, 20×20 intrinsic size) so onboarding Google sign-in and other consumers pick up current branding. > > Adds the missing **`srp-reveal-list__social-icon`** rule (24×24) in `reveal-srp-list/index.scss` so the Google `<img>` on the Secret Recovery Phrase social-login card is sized and visible instead of collapsing to 0×0. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 03829ae. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: Cursor <cursoragent@cursor.com>
## **Description** Refactors the tokens tab E2E page object with reusable helpers and selectors needed by the Tron assets E2E cluster. This is the first slice of the former #44777 split; fixture wiring lands in the follow-up PR stacked on this branch. ## **Changelog** CHANGELOG entry: null ## **Related issues** Part of the local-blockchain E2E initiative (WPN-536). ## **Manual testing steps** 1. `yarn build:test` 2. Verify the branch builds and existing tokens-tab E2E tests still pass. ## **Screenshots/Recordings** N/A — test infrastructure only, no user-facing UI change. ## **Pre-merge author checklist** - [x] 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). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] 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. --------- Co-authored-by: Cursor <cursoragent@cursor.com>
… branches (#44779) ## **Description** Passes four `gate-override-*` inputs so the `AI PR Analyzer / Gate` check concludes `success` for medium-risk Runway cherry-picks into release branches. Fail-closed: trusted same-repo PRs only (forks excluded), author `runway-github[bot]`, base `^release/`, title `cherry.?pick`, risk within `medium`. Off for every other PR. Does not change merge automation by itself. ## **Changelog** CHANGELOG entry: null ## **Related issues** N/A ## **Manual testing steps** 1. A `runway-github[bot]` cherry-pick PR into `release/*` scored `medium` concludes the gate `success` (`Risk gate passed via override: medium ≤ medium`). 2. A `medium` PR into `main`, or from another author, stays `neutral`. ## **Screenshots/Recordings** N/A. CI config change. ### **Before** N/A ### **After** N/A ## **Pre-merge author checklist** - [x] 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). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] 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. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…4790) <!-- 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** Improves the create-password UX so the "passwords don't match" error no longer nags the user on every keystroke while they are still typing the confirmation. The mismatch error now appears only once the confirm field reaches the minimum password length (`PASSWORD_MIN_LENGTH`), and still clears immediately once the values match. ### computeMismatchError: - confirm shorter than min length → false ('abc') - confirm ≥ min length but shorter than password → false ('a]2$GHvw' vs 'a]2$GHvw&W') - confirm ≥ min length, ≥ password length, and differs → true ('X]2$GHvw&W' vs 'a]2$GHvw&W') - confirm === password → false <!-- 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? --> ## **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: show password mismatch error only when confirm password is equal or longer than PASSWORD_MIN_LENGTH ## **Related issues** Fixes: ## **Manual testing steps** 1. Go to Menu > Settings > Security and password > Password 2. Continue until change password form is shown 3. Enter a password and confirm password 4. Before "Passwords don't match" error shows right away after typing first letter of confirm password. It shows now when confirm password is equal to password minimum length which is 8 ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <img width="472" height="488" alt="image" src="https://github.com/user-attachments/assets/b3858f2b-9005-4f95-aa56-7045c14376f1" /> <!-- [screenshots/recordings] --> ### **After** https://github.com/user-attachments/assets/460a223b-e2e3-4981-96fe-33d6e788ec5c <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** - [x] 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). - [x] I've completed the PR template to the best of my ability - [x] I’ve included tests if applicable - [x] I’ve documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] 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] > **Low Risk** > Onboarding/settings password UI validation only; behavior is narrower (fewer premature errors) with no vault or crypto changes. > > **Overview** > **Password confirmation UX** no longer shows “passwords don’t match” on every keystroke while the user is still typing confirm. The shared `PasswordForm` now uses exported **`computeMismatchError`**, which only flags a mismatch when confirm is at least **`PASSWORD_MIN_LENGTH`**, at least as long as the primary password, and not equal—so partial prefixes and short confirm input stay silent until the user has typed enough to judge a real mismatch. > > When the primary password is lengthened after confirm already matched, the mismatch message stays hidden but **`onChange`** still clears the valid password (form stays invalid). Unit coverage was added for the helper and edge cases; onboarding **create-password** and e2e onboarding tests were updated to match the new rules. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 22e1862. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
<!-- 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** Replaces the `selectERC20TokensByChain` Redux selector with the `getAssetImageUrl` utility function in the `GasFeeTokenIcon` component. The previous approach looked up the icon URL from the ERC20 tokens state slice, which has been refactored. The new approach uses the shared `getAssetImageUrl` helper from `asset-utils` to derive the static image URL directly from the token address and chain ID. ## **Changelog** CHANGELOG entry: null ## **Related issues** Fixes: ## **Manual testing steps** 1. Open MetaMask and navigate to a transaction confirmation that uses a gas fee token (pay-with-token flow). 2. Verify the token icon is displayed correctly in the gas fee row. 3. Verify the native token icon is displayed when the native token is selected. ## **Screenshots/Recordings** ### **Before** <!-- [screenshots/recordings] --> ### **After** <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** - [x] 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). - [x] I've completed the PR template to the best of my ability - [x] 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] > **Low Risk** > Localized confirmation UI change with equivalent fallback behavior; no auth or transaction logic touched. > > **Overview** > **Gas fee token icons** on transaction confirmations no longer read `iconUrl` from the `selectERC20TokensByChain` Redux slice. **`GasFeeTokenIcon`** now resolves the image via shared **`getAssetImageUrl(tokenAddress, chainId)`**, keeping the same behavior: **`AvatarToken`** when a URL exists, **`PreferredAvatar`** when it does not. Native-token rendering is unchanged. > > Tests **mock `getAssetImageUrl`**, assert it is called with the token address and confirmation chain ID, and cover both a returned URL and **`undefined`** fallback paths. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 1fc2747. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
<!-- 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? --> ## **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: ## **Related issues** Fixes: ## **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] > **Low Risk** > Dependency version bump plus messenger delegation wiring; no direct changes to auth, keys, or payment flows. > > **Overview** > Upgrades **`@metamask/assets-controller`** from **11.1.1** to **11.2.0** (`package.json` / `yarn.lock`) so the extension picks up the latest package behavior. > > Because **11.2.0** expects remote feature flags on the controller messenger, **`getAssetsControllerMessenger`** now delegates **`RemoteFeatureFlagController:getState`** and **`RemoteFeatureFlagController:stateChange`** to the AssetsController child messenger. The assets-controller messenger unit tests were updated so the delegated action/event lists include those entries. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit b1b2834. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
## **Description** Extends Tron E2E fixtures with assets-focused mocks and environment wiring, and removes staking-only fixture state from the shared helper. Stacks on #44777. ## **Changelog** CHANGELOG entry: null ## **Related issues** Part of the local-blockchain E2E initiative (WPN-536). Stacks on #44777. ## **Manual testing steps** 1. `yarn build:test` 2. Verify the branch builds and existing Tron E2E tests still pass. ## **Screenshots/Recordings** N/A — test infrastructure only, no user-facing UI change. ## **Pre-merge author checklist** - [x] 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). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] 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. Made with [Cursor](https://cursor.com) Co-authored-by: Cursor <cursoragent@cursor.com>
<!-- 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** Adds unit and E2E coverage for the Wallet Imported Segment event, asserting it fires with the expected onboarding properties when an SRP wallet import completes. <!-- 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? --> ## **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: null ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/MMQA-2055 ## **Manual testing steps** CI should pass Execute locally using below commands: yarn test:unit ui/pages/onboarding-flow/create-password/create-password.test.tsx yarn test:e2e:single test/e2e/tests/metrics/wallet-imported.spec.ts --browser=chrome ## **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] > **Low Risk** > Test-only changes with no application or analytics implementation modifications. > > **Overview** > Adds **unit and E2E tests** so the **Wallet Imported** analytics event is verified when SRP import completes during onboarding—no production behavior changes. > > In `create-password.test.tsx`, a new case drives a successful import submit and asserts `trackEvent` emits **Wallet Imported** (onboarding category, `biometrics_enabled: false`) and **Wallet Import Attempted**. Shared helpers `getTrackedEvent` / `getWalletImportedEvent` reduce duplication with existing wallet-setup event checks. > > In `wallet-imported.spec.ts`, a dedicated E2E case mocks Segment for **Wallet Imported**, runs `completeImportSRPOnboardingFlow` with metrics opted in, and asserts a single batch payload with expected properties (`category`, `locale`, `chain_id`, `environment_type`, etc.), with profile IDs stripped pending issue #31860. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit d474157. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
<!-- 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? --> Removes the token approval text and its tooltip from the unified swaps and bridge quote CTA. The MetaMask fee disclaimer remains visible when applicable. Obsolete approval message translations are removed, and the affected tests and snapshots are updated. ## **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: Removed the token approval message and tooltip from swap and bridge quotes ## **Related issues** Fixes: SWAPS-4823 ## **Manual testing steps** 1. Build and load the extension, then unlock the wallet. 2. Open the unified swaps and bridge flow and request an ERC-20 quote that requires token approval, testing both a same-chain swap and a cross-chain bridge. 3. Verify the CTA area does not show an approval sentence or approval tooltip. If a MetaMask fee applies, verify its fee disclaimer remains visible. ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> <img width="477" height="985" alt="Screenshot 2026-07-23 at 10 50 55 AM" src="https://github.com/user-attachments/assets/269a4066-fb19-4852-a9c5-c902d6c35bbb" /> ### **After** <!-- [screenshots/recordings] --> <img width="476" height="917" alt="Screenshot 2026-07-23 at 11 13 17 AM" src="https://github.com/user-attachments/assets/565f2166-426f-4dd6-8ce7-bf9ddaea7b94" /> ## **Pre-merge author checklist** - [x] 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). - [x] I've completed the PR template to the best of my ability - [x] I’ve included tests if applicable - [x] I’ve documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] 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] > **Low Risk** > Copy-only UI change with no transaction or approval logic modified; the main product risk is less upfront disclosure before users confirm approvals. > > **Overview** > Removes **token approval** messaging from the unified swap/bridge quote CTA so users no longer see “approves token for bridge/swap” copy or the **exact-access** info tooltip (including hardware-wallet-specific bridge approval warnings). > > `BridgeCTAInfoText` now only renders the **MetaMask fee disclaimer** when a non-discounted MM fee applies; it renders nothing when the quote needs approval but has no fee text to show. Related **locale strings** (`bridgeApprovalWarning`, `grantExactAccess`, `willApproveAmountForBridging`, etc.) are deleted across locales, with **tests and snapshots** updated to match. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit e13c215. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
…4791) This PR is to make sure that the balance is left aligned for smaller viewports ## **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? --> ## **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: null ## **Related issues** Fixes: ## **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** https://github.com/user-attachments/assets/91524f4d-55e2-44ca-8f00-71a89b3c2f98 ## **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] > **Low Risk** > Presentation-only layout changes in wallet overview with no auth, data, or business-logic impact. > > **Overview** > **Wallet overview balance alignment** is updated so the sidepanel keeps the balance **left-aligned** when the viewport is at or below **490px**, while fullscreen/sidepanel layouts still **center** the balance on wider widths. > > Adds a **`wallet-overview-sidepanel`** class on the sidepanel environment and a shared SCSS mixin that applies `start` alignment under that breakpoint for the balance block, coin overview balance, and loading skeleton. Inline Tailwind alignment on the balance wrapper and skeleton is removed in favor of these styles, and the sidepanel max-width is centralized as a SCSS variable. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit e2e6500. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
<!-- 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** Align the activity transaction details max-width with the recently updated app max width ## **Changelog** CHANGELOG entry: null ## **Related issues** Fixes: #44840 ## **Manual testing steps** 1. Open Activity and click a transaction. 2. Resize the window through narrow, mid (~600–900px), and wide widths. 3. Confirm details always match the app content width with no Activity showing around the edges. 4. Repeat in sidepanel while resizing the panel. <!-- ## **Screenshots/Recordings** ### **Before** ### **After** --> ## **Pre-merge author checklist** - [x] 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). - [x] 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. Made with [Cursor](https://cursor.com) Co-authored-by: Cursor <cursoragent@cursor.com>
## **Description** [PR #43639](#43639) introduced a static route allowlist that let 14 deep-link paths bypass the full-screen interstitial even when a link had a missing or invalid signature. This conflicted with the security decision in [ADR 0011](https://github.com/MetaMask/decisions/blob/8112d93b758f27d09fc86fad09a45da52740ee35/decisions/core/0011-deep-linking-into-wallet.md?plain=1#L92-L93), which requires every deep link to show the interstitial before its destination opens. [PR #44114](#44114) subsequently added `/asset` to the skipped routes. [PR #44639](#44639) replaced that unconditional exception with an asynchronous Token API lookup that allowed assets classified as known-safe to bypass the interstitial. That lookup made `canSkipInterstitial` asynchronous in the non-blocking Manifest V3 request listener, delaying the extension redirect while `link.metamask.io` continued loading its fallback page. This PR restores the protected flow across immediate and deferred deep-link handling: - Deletes the static 14-route bypass allowlist. - Removes the unused `Route.skipInterstitial` property so route definitions cannot opt out of the security boundary. - Deletes the asynchronous `/asset` bypass and its Token API security-data plumbing. Known-safe and unknown or malicious assets now follow the same protected flow. - Restores synchronous `canSkipInterstitial` behavior. Only trusted MetaMask origins, or a valid signature combined with the user's skip preference, can bypass the router-level interstitial. - Keeps all actual deep-link route definitions, including `/asset` and the 14 formerly allowlisted routes. - Documents why `tryNavigateTo` must not perform external network or API lookups before redirecting in MV3: otherwise the fallback page can incorrectly tell users to install MetaMask when it is already installed. Regression coverage exercises missing and invalid signatures for every formerly allowlisted path, protected internal and external redirect destinations, and both known-safe and unknown or malicious asset links. The shared E2E flow once again requires the interstitial before continuing to route destinations. Validation completed: - Focused Jest suites: 116 tests passed - TypeScript type checking passed - Oxfmt and ESLint passed for every changed code file - Full LavaMoat policy regeneration passed for build tooling plus all MV2 and MV3 profiles ## **Changelog** CHANGELOG entry: Fixed deep links so protected routes no longer bypassed the security interstitial based only on their path ## **Related issues** Fixes #44816 Fixes #44817 Fixes #44818 Fixes #44819 Fixes #44820 Fixes #44821 Fixes #44822 Fixes #44823 Fixes #44824 Fixes #44825 Fixes #44826 Fixes #44827 Fixes #44828 Fixes #44829 ## **Manual testing steps** 1. Build and load the Chrome MV3 extension. 2. Open Privacy settings and ensure the option to skip the deep-link interstitial is disabled. 3. Paste `https://link.metamask.io/swap?amount=50` into the browser address bar. 4. Verify the full-screen security interstitial appears before the swap destination opens. 5. Continue through the interstitial and verify the swap destination opens. 6. Paste `https://link.metamask.io/buy` into the browser address bar. 7. Verify the security interstitial appears before the external buy destination opens. 8. Paste `https://link.metamask.io/asset?assetId=eip155%3A1%2Ferc20%3A0x6b175474e89094c44da98b954eedeac495271d0f` into the browser address bar. 9. Verify the known-safe DAI asset link also shows the security interstitial. 10. Repeat with `&sig=aW52YWxpZC1zaWduYXR1cmU=` added to a deep link and verify an invalid signature does not bypass the interstitial. <!-- ## **Screenshots/Recordings** Not applicable; this restores existing interstitial behavior without changing its visuals. ### **Before** N/A ### **After** N/A --> ## **Pre-merge author checklist** - [x] I have 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). - [x] I have completed the PR template to the best of my ability - [x] I have included tests if applicable - [x] I have documented the code using JSDoc format if applicable - [x] I have applied the right labels on the PR ## **Pre-merge reviewer checklist** - [ ] I have manually tested the PR. - [ ] I confirm that this PR addresses all acceptance criteria and includes the necessary testing evidence. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **High Risk** > Changes security-sensitive deep-link navigation for many product routes and removes prior bypass behavior; incorrect logic could block legitimate flows or still expose users to unsigned links. > > **Overview** > Restores ADR-aligned deep-link security by **removing path-based and async asset bypasses** so missing or invalid signatures no longer skip the full-screen interstitial on protected routes (swap, buy, asset, etc.). > > `DeepLinkRouter.canSkipInterstitial` is **synchronous** again: only trusted MetaMask origins, or a **valid signature** plus the user’s skip preference, can bypass. The static allowlist (`interstitial-bypass.ts`), Token API–backed `/asset` checks (`interstitial-bypass-async.ts`), and `Route.skipInterstitial` are deleted; deferred deep-link handling in `utils.ts` matches the same rules. Docs warn that MV3 `onBeforeRequest` must stay free of network work before `redirectTab`. > > Tests and E2E flows now expect the interstitial for unsigned/invalid links on all formerly whitelisted paths and for external redirects from untrusted origins. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 41a4ca9. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
## **Description** - tar to 7.5.22 - Ignoring three react-router advisories because they don't apply to how we're using them, and updating would require a very difficult major version bump ## **Changelog** CHANGELOG entry: null ## **Related issues** Closes: #44805 Progresses: #44859 <!--## **Manual testing steps** ## **Screenshots/Recordings** ## **Pre-merge author checklist** ## **Pre-merge reviewer checklist**--> <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Mostly lockfile and LavaMoat policy alignment plus documented audit suppressions; tar/stream changes affect Snaps packaging but are routine security bumps. > > **Overview** > **Dependency refresh** for the Snaps/tar extraction stack: `tar` moves to **7.5.22**, with related bumps (`tar-stream` 3.2.0, `streamx` 2.28.0, `tar-fs` 2.1.5, and new transitive packages such as `events-universal`, `text-decoder`, and optional `bare-*` peers). `queue-tick` drops out of the `streamx` graph in favor of that newer layout. > > **LavaMoat** webpack policies (MV2/MV3 variants) are regenerated to match: `streamx` now allows `process.nextTick` / `queueMicrotask`, wires `events-universal` and `text-decoder` instead of `queue-tick`, and drops the standalone `queue-tick` entry. > > **Yarn audit** adds three ignored React Router GHSA IDs with rationale—**HashRouter** (not server-controlled browser paths) for the open-redirect issues and **no SSR/hydration** for the `deserializeErrors` advisory—so CI stays green without a major React Router upgrade. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit e846388. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: MetaMask Bot <metamaskbot@users.noreply.github.com>
## **Description** Adds a single automatic retry for `PersistenceManager` write operations. If the first `storage.local` or backup IndexedDB write fails, `PersistenceManager` waits for half of the operation safener debounce window and tries once more before surfacing the existing persistence failure path. Primary `storage.local` retry delays can be canceled when a newer `set` or `persist` supersedes the in-flight write, preventing a stale retry from running. Backup IndexedDB retries are not superseded, so an in-progress vault backup retry still completes before the newer write proceeds. The reason for this split is that a newer primary write contains fresher state, so retrying the older primary write would add storage churn and briefly write stale data. Backup writes are different: by the time a backup retry is waiting, primary storage for that operation has already succeeded. Aborting that backup retry could intentionally leave the recovery backup stale, and in split state the newer write might touch unrelated keys and never refresh backed-up keys such as `KeyringController`. Successful retries emit `writeRetryRecovered`, which is forwarded to Segment as `Data Persistence Write Retry Recovered` with the persistence operation, original error metadata, and retry delay. Also exports `PERSISTENCE_MANAGER_OPERATION_SAFENER_DEBOUNCE_MS` from `PersistenceManager` and uses it to configure the operation safener, so the retry delay is derived from the same shared timing value. ## **Changelog** CHANGELOG entry: null ## **Related issues** Fixes: #44681 ## **Manual testing steps** 1. Run the extension in a Chrome MV3 development build with MetaMetrics enabled so Segment events can be inspected. 2. Trigger a wallet state change while forcing the first persistence write to fail transiently, such as by temporarily making `storage.local.set` reject once in the extension background context. 3. Verify the state write succeeds on the retry, the storage failure UI is not shown, and a `Data Persistence Write Retry Recovered` event is emitted with the original error metadata. 4. While a primary write retry is waiting, trigger and persist a newer state change. Verify the stale retry is canceled and the newer state is written. 5. Force the first backup IndexedDB write to fail, then trigger a newer state change while the retry is waiting. Verify the backup retry still completes before the newer write proceeds. 6. Force both the initial write and retry to fail, then verify the existing storage failure handling still runs. <!-- ## **Screenshots/Recordings** ### **Before** ### **After** --> ## **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). - [x] I've completed the PR template to the best of my ability - [x] 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] > **High Risk** > Changes core wallet persistence and vault backup behavior; incorrect retry or supersede logic could lose state or leave backups stale, though existing failure paths remain when both attempts fail. > > **Overview** > Adds a **single automatic retry** for `PersistenceManager` `set`/`persist` paths and IndexedDB vault backup writes. After the first failure it waits **500ms** (half the shared operation-safener debounce) and tries once more before the existing failure UI and Sentry reporting. > > **Primary** `storage.local` retries can be **canceled** when a newer `set` or `persist` supersedes the in-flight write, so stale state is not written. **Backup** IndexedDB retries are **not** superseded so an in-progress vault backup can finish before newer writes proceed. > > Successful retries emit `writeRetryRecovered`, wired in `setup-initial-state-hooks` to Segment as **`Data Persistence Write Retry Recovered`** with operation name, original error metadata, and retry delay. **`PERSISTENCE_MANAGER_OPERATION_SAFENER_DEBOUNCE_MS`** is exported and reused by `safe-reload` debouncing. > > Test support: `simulateStorageSetFailure` accepts **`'once'`** (first write per manager instance only). Unit and e2e coverage added for retry, supersede, and analytics. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 708f9ff. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: Jongsun Suh <jongsun.suh@icloud.com>
… cp-13.42.0 (#44863) ## **Description** Fixes the dark theme regression in transaction details introduced by #44599 (native \`<dialog>\` refactor). The browser UA stylesheet sets \`color: canvastext\` directly on \`<dialog>\` elements, which overrides the inherited \`color: var(--color-text-default)\` from \`html[data-theme]\`. Because \`canvastext\` resolves based on the browser's native color-scheme rather than MetaMask's \`data-theme\` attribute, text inside the dialog renders with the wrong color in dark mode. Adding \`text-default\` here sets the MMDS color token as an author style directly on the dialog element, taking precedence over the UA rule and restoring correct text color for all descendants. ## **Changelog** CHANGELOG entry: null ## **Related issues** Fixes #44836 ## **Manual testing steps** > **Note:** The bug only reproduces when your OS/system theme differs from the MetaMask theme. Set your OS to **light** mode and MetaMask to **dark** mode to trigger it. 1. Set OS appearance to Light mode 2. In MetaMask, go to Settings → General → Theme → Dark 3. Go to Activity 4. Click any transaction 5. Verify all text in the transaction details dialog is visible (white/light on dark background, not invisible black) ## **Screenshots/Recordings** ### **Before** <img width="1506" height="869" alt="Screenshot 2026-07-24 at 1 34 22 PM" src="https://github.com/user-attachments/assets/825237cc-e95b-4915-abf1-d94aa1cebdf6" /> <img width="451" height="624" alt="Image" src="https://github.com/user-attachments/assets/fa5e2a3a-4153-40e9-a821-fc7e9e9417b3" /> ### **After** <img width="1507" height="871" alt="Screenshot 2026-07-24 at 1 31 51 PM" src="https://github.com/user-attachments/assets/34383cb5-1e6f-46d8-a15a-a05411510fba" /> <img width="455" height="651" alt="Image" src="https://github.com/user-attachments/assets/289b0c93-f702-4645-a2a0-680f4406b593" /> ## **Pre-merge author checklist** - [x] 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). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] 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.
<!-- 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** Fixes the locally enriched bridge transaction title text that incorrectly changes when switching to a non-EVM network ## **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: fix: local bridge activity label when switching to non-evm accounts ## **Related issues** Fixes: #44591 ## **Manual testing steps** 1. Do a token bridge 2. Switch network to Bitcoin ## **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] > **Medium Risk** > Changes which transactions appear in local activity and how bridge labels resolve when multichain network selection differs from EVM account; limited to activity UI/selectors, not funds or auth. > > **Overview** > Fixes **local activity / bridge label enrichment** when the user switches to a non-EVM network (e.g. Bitcoin) while staying on the same account group. > > `selectLocalTransactions` and `selectLocalActivityItems` now filter and enrich using **`selectEvmAddress`** (the EVM account in the selected group) instead of **`getSelectedInternalAccount`** (which tracks the network-selected account). **`selectEvmAddress`** is defined earlier in `activity.ts` so those selectors can depend on it. > > Across locale files, **`activity_deposit_*_description`** strings are cleared to empty messages (titles unchanged), so deposit rows no longer show redundant subtitle copy. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 07b9d35. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> Co-authored-by: Cursor <cursoragent@cursor.com>
## **Description** This PR adds the Tron network E2E cluster and the `home-network-filter` page object it depends on. It is one reviewable step of a linear stack and replaces #43659. Validated locally: `network.spec.ts` passes 5/6, with the 1 failure being an element-visibility timeout that is likely local flake — CI is the arbiter. Based on a fresh `main` and under 1000 changed lines. ## **Changelog** CHANGELOG entry: null ## **Related issues** Part of the local-blockchain E2E initiative (WPN-536). Replaces #43659. ## **Manual testing steps** 1. `yarn build:test` 2. `yarn test:e2e:single test/e2e/tests/tron/network.spec.ts --browser=chrome` (locally 5/6; the 1 element-visibility timeout is likely local flake — CI is the arbiter). ## **Screenshots/Recordings** N/A — test infrastructure only, no user-facing UI change. ## **Pre-merge author checklist** - [x] 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). - [x] I've completed the PR template to the best of my ability - [x] I’ve included tests if applicable - [x] I’ve documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] 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. --------- Co-authored-by: Cursor <cursoragent@cursor.com>
<!-- 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** Cleanup and replace deprecated selectors ## **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: null ## **Related issues** Fixes: ## **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] > **Medium Risk** > Bridge history matching is narrower than the removed multi-field `getBridgeHistoryItem` logic, so bridge/swap activity status and intent-bridge pending cancel/speed-up rules could differ in edge cases. > > **Overview** > **Centralizes bridge history resolution** for activity and pending-transaction UI by adding exported `selectBridgeHistoryItemForTx`, which resolves by tx hash (via bridge-status selectors), direct `txHistory` key on meta id, then original tx meta id. > > **Activity selectors** drop the deprecated raw `txHistory` selector and the inline `getBridgeHistoryItem` group scan; local swap/bridge rows now call the shared lookup with `initialTransaction` only, and non-EVM bridge enrichment passes `{ hash: transaction.id }` instead of id-only. > > **Pending transaction actions** read bridge history through `useSelector` + `selectBridgeHistoryItemForTx` instead of `useBridgeTxHistoryData`; tests mock Redux and the new selector accordingly. A JSDoc note on `hasIntentBridgeActivity` was removed from the hook params type only. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit db8cad3. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: Cursor <cursoragent@cursor.com>
## **Description** After a Chrome Web Store upload is approved and published, rollout percentage is today adjusted manually in the CWS Developer Dashboard. This PR adds an audited, human-initiated path to raise deploy percentage via CWS API v2. **Problem:** Manual dashboard changes are hard to audit and easy to mis-apply (rollback, large jumps, 100% without explicit confirmation). **Solution:** - New `.github/workflows/adjust-cws-rollout.yml` — `workflow_dispatch` only; targets `dev`, `production`, `flask` (aligned with INFRA-3734 upload model). - **Separate from upload:** upload = Runway + WIF on `cws-dev` / `cws-production` / `cws-flask` (draft only). Rollout = human judgment after monitoring (`docs/sensitive-release.md` 1% protocol). - **Authorization:** dedicated rollout GitHub Environments with required reviewers (platform must create): - `cws-rollout-dev` (UAT smoke) - `cws-rollout-production` (main listing) - `cws-rollout-flask` (Flask listing) - Bot/Runway dispatch explicitly rejected; human initiates → environment approver confirms → guardrails → CWS API. - Guardrails script reports **all** violations before exit (range, no rollback, 100% confirm, 50-point max step). - CWS v2 `:fetchStatus` for current `deployPercentage`; `:setPublishedDeployPercentage` to apply. - `if: always()` audit summary (actor, environment, target, version, previous/requested %, run URL). **Open question (see INFRA-3651):** Runway-driven vs workflow-driven rollout for production — pending Mark / Gauthier / Victor. **Platform follow-up (not in this PR):** 1. Create `cws-rollout-*` GitHub Environments + required reviewers (after RE confirmation). 2. Extend GCP WIF CEL + IAM bindings for rollout envs on dev and prod (`adjust-cws-rollout.yml`; no Runway pin on rollout path). ## **Changelog** CHANGELOG entry: null ## **Related issues** Fixes: [INFRA-3651](https://consensyssoftware.atlassian.net/browse/INFRA-3651) ## **Manual testing steps** **Prerequisite:** Platform creates `cws-rollout-dev` / `cws-rollout-production` / `cws-rollout-flask` and WIF CEL for `adjust-cws-rollout.yml`. 1. **Dev — rollback:** Published version at e.g. 10%; dispatch `desired_percentage=5` → guardrails fail with rollback message; attach run link to INFRA-3651. 2. **Dev — 100% without confirm:** Dispatch `desired_percentage=100` without `confirm_full_rollout=yes` → guardrails fail; attach run link. 3. **Dev — success:** Valid version, e.g. 5% → 10% → guardrails pass → CWS updated; audit summary correct; attach run link. 4. **Production — bot block:** Any bot dispatch → rejected before GCP auth; attach run link. 5. **Production — human success:** RE dispatches → environment approver confirms → rollout updated on production listing; attach run link. 6. **Flask — human success:** Same as production on Flask listing (`EXTENSION_ID_FLASK`); attach run link. ## **Screenshots/Recordings** N/A — CI/workflow only; evidence is GitHub Actions run summaries and CWS listing state. ### **Before** N/A ### **After** N/A ## **Pre-merge author checklist** - [x] 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). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] 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)). ## **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. [INFRA-3651]: https://consensyssoftware.atlassian.net/browse/INFRA-3651?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Changes who can move production extension rollout % and how (WIF + CWS API), but bots are blocked, rollbacks are refused in-workflow, and GitHub Environment reviewers are required before apply. > > **Overview** > Adds a **human-only** GitHub Actions path to raise Chrome Web Store **published deploy percentage** after upload, separate from `upload-extension-to-cws.yml` (Runway/draft upload). > > New **`adjust-cws-rollout.yml`** is `workflow_dispatch` with inputs for manifest **version**, **desired_percentage** (1–100), and **target** (`dev` / `production` / `flask`). Each target maps to a dedicated **`cws-rollout-*` GitHub Environment** (required reviewers), rejects **Bot** senders, requires **`refs/heads/main`**, resolves WIF/listing vars like the upload workflow, and authenticates to CWS with the chromewebstore scope. > > The job calls **`:fetchStatus`**, derives **current** `deployPercentage` only from the **live published** `crxVersion` (Flask uses `{version}-flask.0`), then runs **`adjust-cws-rollout-guardrails.sh`** (valid ranges, **no rollback** when desired < current, no-op when equal) before **`:setPublishedDeployPercentage`**. An **`if: always()`** step writes an audit table to the run summary (actor, env, target, version, before/after %, step outcomes). > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 88a5e3e. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: Alejandro Som <560018+alucardzom@users.noreply.github.com>
Contributor
Builds ready [a694e1e]
⚡ Performance Benchmarks (Total: 🟢 9 pass · 🟡 9 warn · 🔴 4 fail)
Bundle size diffs [🚨 Warning! Bundle size has increased!]
🍒 What's in this RCCherry-picks (9 commits)
Changelog (159 commits since v13.42.0)
AI Test Plan
Cherry-Pick Scenarios (2)High Risk Scenarios (1)1. Smart Transactions: Tx Sentinel URL change (monitoring and status updates)Risk Level: HIGH Why This Matters: Cherry-pick 45214 fixes Smart Transactions monitoring by updating the tx-sentinel URL; incorrect wiring can cause missing status updates, user confusion, or stuck transactions. Test Steps:
Medium Risk Scenarios (1)1. Perpetuals: Order book added to order entry pageRisk Level: MEDIUM Why This Matters: Cherry-pick 45151 adds critical UI to the perps trading flow; rendering or data-binding issues can block trading or display misleading liquidity. Test Steps:
Release Scenarios (9)High Risk Scenarios (5)1. State Migrations: 220 - core wallet/state preservationRisk Level: HIGH Why This Matters: New state migrations can inadvertently drop or corrupt persisted wallet data. Validating preservation of accounts, networks, tokens, and connections prevents critical data loss for users after upgrade. Test Steps:
2. State Migrations: 221 - analytics/metametrics and preferencesRisk Level: HIGH Why This Matters: Migrations adjusting analytics/metametrics state can silently flip consent or break event gating, leading to privacy violations or missing telemetry. Test Steps:
3. Assets/Home: Asset List Control Bar and Network FilterRisk Level: HIGH Why This Matters: Significant UI logic changes in filtering and totals can cause incorrect balances, missing assets, or confusing UX in the most-used screen. Test Steps:
4. Network Management: Invalid Custom Network AlertRisk Level: HIGH Why This Matters: Preventing users from using misconfigured networks avoids failed transactions, fund loss risks, and confusing network behaviors. Test Steps:
5. Analytics/Metametrics Controller: Consent gating and event flowRisk Level: HIGH Why This Matters: Large refactors in the analytics controller risk privacy regressions or loss of telemetry needed to monitor product health. Test Steps:
Medium Risk Scenarios (4)1. Balances: Account Group Balance accuracy across filtersRisk Level: MEDIUM Why This Matters: Incorrect total balances undermine user trust and can impact financial decisions within the wallet. Test Steps:
2. Site Connections: Unconnected Account AlertRisk Level: MEDIUM Why This Matters: Clear, accurate connection status prevents signing with the wrong account and reduces phishing/privilege confusion. Test Steps:
3. App State Controller: Lock/Unlock and rapid state transitionsRisk Level: MEDIUM Why This Matters: Changes in app-state logic can lead to race conditions that freeze the UI or show stale data during common actions. Test Steps:
4. Error Handling: API error surfaces without blocking core flowsRisk Level: MEDIUM Why This Matters: Graceful error handling avoids user confusion and ensures the wallet remains usable during transient API issues. Test Steps:
Teams Sign-off StatusSigned off: None yet Awaiting sign-off (5): Generated by AI Test Plan Analyzer (gpt-5) at 2026-08-05T19:19:54.591Z AI generated test plan (JSON): test-plan-13.43.0.json |
![https://cursor.com/assets/images/open-in-web-dark.png"><source](https://cursor.com/assets/images/open-in-web-dark.png"><source){kind=link}
![https://cursor.com/assets/images/open-in-web-light.png"><img](https://cursor.com/assets/images/open-in-web-light.png"><img){kind=link}
![https://cursor.com/assets/images/open-in-web-dark.png"></picture></a> <a](https://cursor.com/assets/images/open-in-web-dark.png"></picture></a> <a){kind=link}
![https://cursor.com/assets/images/open-in-cursor-dark.png"><source](https://cursor.com/assets/images/open-in-cursor-dark.png"><source){kind=link}
![https://cursor.com/assets/images/open-in-cursor-light.png"><img](https://cursor.com/assets/images/open-in-cursor-light.png"><img){kind=link}
![https://cursor.com/assets/images/open-in-cursor-dark.png"></picture></a> </div](https://cursor.com/assets/images/open-in-cursor-dark.png"></picture></a> </div){kind=link}
…yarn audit (#45252) - fix: resolve ip-address to >=10.3.1 for yarn audit cp-13.43.0 (#45243) <!-- 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? --> Adds resolution for `ip-address@^10.3.1` to fix 3 yarn audit advisories: - GHSA-mwp4-54f8-5fhr (HIGH) - GHSA-4xrf-jv44-h6hh (MODERATE) - GHSA-22jq-vg5j-6vgg (MODERATE) Failure: https://github.com/MetaMask/metamask-extension/actions/runs/30963484287/job/92172879892 [Slack thread ](https://consensys.slack.com/archives/C0BLWRC2TRB/p1785924452227219?thread_ts=1785892716.329899&cid=C0BLWRC2TRB) Dependency chain: `socks` → `ip-address@10.2.0` (vulnerable) Cherry-pick to `release/13.43.0` required. ## **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: null ## **Related issues** Fixes: #45163 ## **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. --> N/A ### **Before** <!-- [screenshots/recordings] --> N/A ### **After** <!-- [screenshots/recordings] --> N/A ## **Pre-merge author checklist** - [x] 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). - [x] 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 - [x] 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] > **Low Risk** > Lockfile-only security bump with no runtime code changes; risk is limited to behavior differences in the patched `ip-address` library used by SOCKS-related tooling. > > **Overview** > Adds a Yarn **`resolutions`** entry for **`ip-address@^10.3.1`**, forcing the lockfile from **10.2.0** to **10.4.0** so **`yarn audit`** clears three advisories on the transitive copy pulled in via **`socks`**. > > No application or extension source changes—only **`package.json`** and **`yarn.lock`**. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 81ecc01. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> [9c34c81](9c34c81) --------- Co-authored-by: sleepytanya <104780023+sleepytanya@users.noreply.github.com> Co-authored-by: MetaMask Bot <metamaskbot@users.noreply.github.com>
Contributor
Builds ready [cb83da7]
⚡ Performance Benchmarks (Total: 🟢 7 pass · 🟡 9 warn · 🔴 4 fail)
Bundle size diffs [🚨 Warning! Bundle size has increased!]
🍒 What's in this RCCherry-picks (10 commits)
Changelog (160 commits since v13.42.0)
AI Test Plan
Cherry-Pick Scenarios (2)High Risk Scenarios (1)1. Smart Transactions – Sentinel Status/URL PatchRisk Level: HIGH Why This Matters: Cherry-pick 45214 fixes sentinel URL coverage; incorrect sentinel endpoints can cause missing or stuck status updates, broken cancels/speed-ups, and user confusion. Test Steps:
Medium Risk Scenarios (1)1. Perpetuals – Order Book on Order Entry PageRisk Level: MEDIUM Why This Matters: Cherry-pick 45151 adds a new live order book to a trading-critical screen; incorrect interactions or stale data can lead to wrong pricing and failed orders. Test Steps:
Release Scenarios (12)High Risk Scenarios (6)1. State Migrations (versions 220 and 221) – Upgrade with complex user stateRisk Level: HIGH Why This Matters: Migrations can corrupt or drop critical user data (accounts, permissions, tokens) or leave the extension unusable; verifying upgrade preserves state is essential. Test Steps:
2. Auto-lock and Pending Approval/Transaction ResilienceRisk Level: HIGH Why This Matters: Recent app-state-controller changes can break approval flows if auto-lock/unlock interrupts them, risking user funds or stuck approvals. Test Steps:
3. Site Connections – Unconnected Account AlertRisk Level: HIGH Why This Matters: The alert guards users from transacting with the wrong account; regressions can cause silent misrouting of transactions or user confusion. Test Steps:
4. Network Management – Invalid Custom Network AlertRisk Level: HIGH Why This Matters: Misconfigured networks can cause irreversible loss of funds; the alert must reliably detect and prevent risky actions. Test Steps:
5. MetaMetrics Consent and Event Gating (Onboarding and Settings)Risk Level: HIGH Why This Matters: Large metametrics-controller changes risk privacy regressions (events sent when opted out) or broken analytics that impair product decisions. Test Steps:
6. Assets List – Network Filter and Control BarRisk Level: HIGH Why This Matters: Recent control bar and filter changes can lead to incorrect balances, missing tokens, or misleading totals, affecting user trust and actions. Test Steps:
Medium Risk Scenarios (6)1. Account Group Balance – Aggregation AccuracyRisk Level: MEDIUM Why This Matters: Incorrect aggregated balances lead to faulty decisions; updates to this component are error-prone and impact user confidence. Test Steps:
2. Activity Feed and Notifications – Action Type UpdatesRisk Level: MEDIUM Why This Matters: Changes to controller method/action types can desynchronize activity labeling, causing duplicates, missing entries, or wrong statuses. Test Steps:
3. Perpetuals – Streaming Data Stability (baseline)Risk Level: MEDIUM Why This Matters: Recent perps streaming code changes can create UI stalls, stale data, or reconnection failures that compromise trading UX. Test Steps:
4. Send/Swap Initiation from Filtered Asset ViewsRisk Level: MEDIUM Why This Matters: Filter and control bar changes can leak or misapply context into transaction flows, causing misrouted or failed transactions. Test Steps:
5. Connected Sites Permissions Integrity Post-MigrationRisk Level: MEDIUM Why This Matters: Migrations can silently alter permission state leading to broken dapp connections or unintended access. Test Steps:
6. Onboarding – MetaMetrics and First-Run UXRisk Level: MEDIUM Why This Matters: Controller and metrics changes can break first-run flows, causing incomplete setup or incorrect privacy defaults. Test Steps:
Teams Sign-off StatusSigned off: None yet Awaiting sign-off (9): Generated by AI Test Plan Analyzer (gpt-5) at 2026-08-05T20:37:55.244Z AI generated test plan (JSON): test-plan-13.43.0.json |
Contributor
Builds ready [cb83da7]
⚡ Performance Benchmarks (Total: 🟢 11 pass · 🟡 9 warn · 🔴 4 fail)
Bundle size diffs [🚨 Warning! Bundle size has increased!]
🍒 What's in this RCCherry-picks (10 commits)
Changelog (160 commits since v13.42.0)
AI Test Plan
Cherry-Pick Scenarios (2)High Risk Scenarios (1)1. Smart Transactions — Tx Sentinel routing (robinhood URL)Risk Level: HIGH Why This Matters: Cherry-pick 45214 fixes Smart Transactions routing by adding a new sentinel endpoint; incorrect wiring breaks STX preflight/monitoring and can block transactions. Test Steps:
Medium Risk Scenarios (1)1. Perps — Order book in order entry pageRisk Level: MEDIUM Why This Matters: Cherry-pick 45151 adds a new order book to trading; bad subscriptions or UI wiring can misprice orders or block order entry. Test Steps:
Release Scenarios (12)High Risk Scenarios (4)1. State Migrations (220, 221) — Core data integrityRisk Level: HIGH Why This Matters: Migrations can corrupt or drop user data (accounts/networks/tokens). Verifying end-to-end persistence prevents loss of funds visibility and broken network setups. Test Steps:
2. State Migrations (220, 221) — Permissions, Connected Sites, SnapsRisk Level: HIGH Why This Matters: Permission graphs are sensitive to schema changes; corruption here can cause security/privacy regressions or break dapp/Snap functionality. Test Steps:
3. State Migrations (220, 221) — Pending transactions and Activity logRisk Level: HIGH Why This Matters: Users must not lose visibility or control of pending transactions across migrations; broken histories cause confusion and potential double-spend attempts. Test Steps:
4. Bridge — Route selection, approvals, and executionRisk Level: HIGH Why This Matters: Bridge logic or controller changes can silently break routing or approvals; users risk stalled or failed fund transfers. Test Steps:
Medium Risk Scenarios (8)1. MetaMetrics (analytics) — Opt-in/out gating and event emissionRisk Level: MEDIUM Why This Matters: A large refactor to the metametrics controller can accidentally over/under-report or re-prompt users, creating privacy and compliance risks. Test Steps:
2. Assets — Network filter and control barRisk Level: MEDIUM Why This Matters: Changes in filtering can hide assets, misstate balances, or confuse users switching networks. Test Steps:
3. Balances — Account group balance calculationsRisk Level: MEDIUM Why This Matters: Incorrect aggregation or currency conversion misrepresents portfolio value and can drive poor user decisions. Test Steps:
4. Alerts — Unconnected account and invalid custom networkRisk Level: MEDIUM Why This Matters: Connection and network mismatch alerts guide safe interaction with dapps; regressions can lead to failed transactions or using the wrong account/network. Test Steps:
5. Perps — Market data stream resilience (baseline)Risk Level: MEDIUM Why This Matters: Real-time data streams must recover from disconnects and market switches; failures degrade trading accuracy and user trust. Test Steps:
6. App State — Lock/unlock and session restorationRisk Level: MEDIUM Why This Matters: App-state controller changes can cause lost context or stuck spinners after authentication and restarts. Test Steps:
7. Send — Custom network transaction and activity visibilityRisk Level: MEDIUM Why This Matters: Network-aware UI changes can desync send/confirm flows and activity visibility, leading to user confusion about transaction status. Test Steps:
8. Onboarding UX — Account icon tourRisk Level: MEDIUM Why This Matters: A misbehaving tour can block key controls or become a recurring annoyance, harming first-run UX. Test Steps:
Teams Sign-off StatusSigned off: None yet Awaiting sign-off (8): Generated by AI Test Plan Analyzer (gpt-5) at 2026-08-05T22:04:14.070Z AI generated test plan (JSON): test-plan-13.43.0.json |
This was referenced Aug 6, 2026
Merged
Merged
…o release/*; block flask dispatch (#45326) - fix(ci): restrict AMO flask/production to release/*; block flask dispatch (#45302) ## **Description** Align AMO **production** and **flask** to **`release/*` only** (not `main`) so uploads use the same workflow version as the cut. Flask remains orchestrator-only: `flask` is removed from `workflow_dispatch` target options, and the sender check rejects any human/non-Runway flask dispatch. Do **not** gate on `github.event_name` — in a reusable workflow that value is the caller's trigger, so a Runway orchestrator `workflow_call` (itself `workflow_dispatch`) would falsely fail. Keep `workflow_call` for Runway Phase 3. **Companion:** [infra PR #19](https://github.com/consensys-vertical-apps/va-mmc-extension-submission-infra/pull/19) (`amo-submission-flask` + `amo-submission-production` OIDC `release/*` only). Docs: [releases#32](https://github.com/MetaMask/releases/pull/32). **GitHub Environment config (done):** - [x] Remove required reviewers on `amo-flask` - [x] Set `amo-flask` and `amo-production` deployment branches to **`release/*` only** (remove `main`) ## **Changelog** CHANGELOG entry: null ## **Related issues** Fixes: INFRA-3769 ## **Manual testing steps** 1. On `release/X.Y.Z`, Actions → Upload extension to Firefox AMO — targets are `production` and `dev` only (`flask` not offered). 2. `target=production` on `release/*` passes the branch guard (then waits on `amo-production` approval). 3. `target=production` on `main` fails the branch guard. 4. Orchestrator `workflow_call` with `target=flask` still succeeds (sender = Runway; no env reviewers on `amo-flask`). 5. Human attempt at flask (API/`workflow_call` from a user) fails the sender check before AWS creds. ## **Screenshots/Recordings** N/A ### **Before** N/A ### **After** N/A ## **Pre-merge author checklist** - [x] 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). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] 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. --------- Co-authored-by: Cursor <cursoragent@cursor.com> [bc18c5c](bc18c5c) Co-authored-by: Borislav Grigorov <11405770+bsgrigorov@users.noreply.github.com> Co-authored-by: Cursor <cursoragent@cursor.com>
Contributor
Builds ready [eab4097]
⚡ Performance Benchmarks (Total: 🟢 12 pass · 🟡 6 warn · 🔴 4 fail)
Bundle size diffs [🚨 Warning! Bundle size has increased!]
🍒 What's in this RCCherry-picks (11 commits)
Changelog (161 commits since v13.42.0)
AI Test Plan
Cherry-Pick Scenarios (2)High Risk Scenarios (1)1. Smart Transactions – Tx Sentinel (Robinhood) RoutingRisk Level: HIGH Why This Matters: Cherry-pick 45214 fixes Smart Transactions controller endpoint routing to the tx-sentinel Robinhood URL; incorrect routing can break submissions or status updates and strand user transactions. Test Steps:
Medium Risk Scenarios (1)1. Perps – Order Entry Page Order BookRisk Level: MEDIUM Why This Matters: Cherry-pick 45151 adds a new order book on the order entry page; visual correctness and real-time updates are critical for trading accuracy and user trust. Test Steps:
Release Scenarios (10)High Risk Scenarios (4)1. State Migrations (versions 220 and 221)Risk Level: HIGH Why This Matters: Migrations can corrupt or drop user data; verifying persistence across upgrade prevents loss of funds access, incorrect privacy settings, or broken networks. Test Steps:
2. Smart Transactions (send/swap flows, speed up/cancel)Risk Level: HIGH Why This Matters: Controller logic and patches around Smart Transactions directly impact transaction reliability, fees, and recoverability (speed up/cancel). Test Steps:
3. Assets List Control Bar and Network FilterRisk Level: HIGH Why This Matters: Substantial UI changes to filtering and totals can misrepresent balances or hide assets, causing user confusion and potential transaction mistakes. Test Steps:
4. MetaMetrics Consent and Tracking (Metametrics Controller refactor)Risk Level: HIGH Why This Matters: Refactors to telemetry can accidentally re-prompt users, flip consent, or leak events contrary to user privacy choices. Test Steps:
Medium Risk Scenarios (6)1. Invalid Custom Network AlertRisk Level: MEDIUM Why This Matters: Users can be blocked from transacting or misled to wrong chains if chainId/RPC mismatches aren’t handled clearly and safely. Test Steps:
2. Unconnected Account Alert (Dapp permissions vs active account)Risk Level: MEDIUM Why This Matters: Prevents accidental transactions from the wrong account and ensures clear, safe user decisions with connected sites. Test Steps:
3. Account Group Balance AccuracyRisk Level: MEDIUM Why This Matters: Incorrect aggregation or currency conversion can misrepresent portfolio value and lead to poor user decisions. Test Steps:
4. Perps Streaming Data (Perps Stream Bridge)Risk Level: MEDIUM Why This Matters: Live data reliability is essential for trading UIs; stream reconnect failures or stale data can lead to incorrect actions. Test Steps:
5. Account Icon Tour (Onboarding Hints via App State Controller)Risk Level: MEDIUM Why This Matters: App-state changes can cause onboarding tips to reappear or never show, degrading UX accessibility and guidance. Test Steps:
6. API Error Handling (User-facing error surfaces)Risk Level: MEDIUM Why This Matters: Clear, non-blocking error handling avoids user confusion and ensures recovery from transient failures. Test Steps:
Teams Sign-off StatusSigned off: None yet Awaiting sign-off (9): Generated by AI Test Plan Analyzer (gpt-5) at 2026-08-07T18:20:51.052Z AI generated test plan (JSON): test-plan-13.43.0.json |
…attestations permissions they request (#45336) - fix(ci): grant orchestrator callees the attestations permissions they request (#45330) ## **Description** The Runway release orchestrator (`runway-extension-release-and-submit.yml`) fails at run creation, before any job starts: ``` Error calling workflow '.../publish-release-from-release-head.yml@eab4097'. The nested job 'publish-release' is requesting 'attestations: write', but is only allowed 'attestations: none'. ``` A called workflow can never hold more permission than the job that calls it. The orchestrator's calling jobs inherited only `contents/statuses/actions: read` + `id-token: write`, but two callees ask for attestation scopes: | Callee | Needs | Why | | --- | --- | --- | | `publish-release-from-release-head.yml` | `attestations: write` | `actions/attest-build-provenance` (INFRA-2665) | | `upload-extension-to-cws.yml` | `attestations: read` | `gh attestation verify` (INFRA-3661) | This grants those scopes on the calling jobs rather than workflow-wide, so `validate` and the AMO phase keep the narrower set. Because a job-level `permissions:` block replaces the workflow-level one, each block lists the full union the callee needs. Also removes a reference to a `version` input from the recovery text in the orchestrator summary. There is no `version` input; the version is derived from the `release/X.Y.Z` branch the workflow runs on. Not addressed here: `actionlint` and `zizmor` lint one file at a time and do not inspect the reusable-workflow call graph, so no linter catches this class of error. It only surfaces on dispatch. ## **Changelog** CHANGELOG entry: null ## **Related issues** Fixes: INFRA-3735 follow-up (orchestrator was never dispatched end-to-end before 13.43.0) ## **Manual testing steps** 1. Dispatch **Runway extension release and store submit** on a `release/*` branch with `execute_store_phases=false` (validation-only run). 2. Confirm the run is created, i.e. no `The workflow is not valid ... attestations: none` error. On `main` today, run creation fails at this point. 3. Confirm Phase 0 validation passes and Phases 1 to 3 are skipped. 4. Open the orchestrator summary and confirm the recovery line reads "re-dispatch from the same release branch with the same `release_sha`". <!-- ## **Screenshots/Recordings** ### **Before** ### **After** --> ## **Pre-merge author checklist** - [x] 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). - [x] 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. Made with [Cursor](https://cursor.com) Co-authored-by: Cursor <cursoragent@cursor.com> [0040e9f](0040e9f) Co-authored-by: Borislav Grigorov <11405770+bsgrigorov@users.noreply.github.com> Co-authored-by: Cursor <cursoragent@cursor.com>
Contributor
Builds ready [dfc2567]
⚡ Performance Benchmarks (Total: 🟢 10 pass · 🟡 7 warn · 🔴 4 fail)
Bundle size diffs [🚨 Warning! Bundle size has increased!]
🍒 What's in this RCCherry-picks (12 commits)
Changelog (162 commits since v13.42.0)
AI Test Plan
Cherry-Pick Scenarios (2)High Risk Scenarios (1)1. Smart Transactions - Sentinel endpoint routingRisk Level: HIGH Why This Matters: Cherry-pick #45214 fixes STX controller routing; incorrect endpoints can break all STX sends or strand users mid-flow. Test Steps:
Medium Risk Scenarios (1)1. Perps - Order book on order entry pageRisk Level: MEDIUM Why This Matters: Cherry-pick #45151 adds a new user-facing order book; incorrect wiring can misprice orders or break trading UX. Test Steps:
Release Scenarios (10)High Risk Scenarios (5)1. State Migrations 220/221 - Persistent state integrityRisk Level: HIGH Why This Matters: New migrations can corrupt or drop user data (accounts, networks, tokens, pending approvals) and block core wallet flows. Test Steps:
2. State Migrations 220/221 - Metametrics consent and defaultsRisk Level: HIGH Why This Matters: Metametrics-controller changes can mistakenly flip consent or leak PII, creating privacy regressions post-migration. Test Steps:
3. Smart Transactions - submit and fallbackRisk Level: HIGH Why This Matters: Controller and patch changes around Smart Transactions can break send flows or strand users in non-functional routes. Test Steps:
4. Dapp Permissions - Unconnected account alertRisk Level: HIGH Why This Matters: Incorrect unconnected-account gating can silently block dapp flows or allow unintended account access. Test Steps:
5. Balances - Account group balance accuracyRisk Level: HIGH Why This Matters: Incorrect aggregation or stale state can misrepresent user funds, eroding trust in balances shown. Test Steps:
Medium Risk Scenarios (5)1. Perps - Live market data stream resilienceRisk Level: MEDIUM Why This Matters: Perps stream bridge changes can cause stalls or memory leaks, breaking real-time trading UX. Test Steps:
2. Network Management - Invalid custom network alertRisk Level: MEDIUM Why This Matters: Incorrect or noisy network validation interrupts normal use and may mislead users about network safety. Test Steps:
3. Assets - Network filter and control bar behaviorsRisk Level: MEDIUM Why This Matters: Filter logic regressions can hide assets or confuse totals, leading to missed funds or actions. Test Steps:
4. App State - Route and UI state persistenceRisk Level: MEDIUM Why This Matters: App-state-controller changes can create jarring resets or stuck UI flows after lock/unlock or reload. Test Steps:
5. Analytics Events - Emission and redactionRisk Level: MEDIUM Why This Matters: Refactors in the metametrics controller may alter event names or redaction, risking broken dashboards or privacy leaks. Test Steps:
Teams Sign-off StatusSigned off: None yet Awaiting sign-off (6): Generated by AI Test Plan Analyzer (gpt-5) at 2026-08-08T02:10:15.163Z AI generated test plan (JSON): test-plan-13.43.0.json |
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
20 participants
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.
🚀 v13.43.0 Testing & Release Quality Process
Hi Team,
As part of our new MetaMask Release Quality Process, here’s a quick overview of the key processes, testing strategies, and milestones to ensure a smooth and high-quality deployment.
📋 Key Processes
Testing Strategy
Conduct regression and exploratory testing for your functional areas, including automated and manual tests for critical workflows.
Focus on exploratory testing across the wallet, prioritize high-impact areas, and triage any Sentry errors found during testing.
Validate new functionalities and provide feedback to support release monitoring.
GitHub Signoff
Issue Resolution
Cherry-Picking Criteria
🗓️ Timeline and Milestones
✅ Signoff Checklist
Each team is responsible for signing off via GitHub. Use the checkbox below to track signoff completion:
Team sign-off checklist
This process is a major step forward in ensuring release stability and quality. Let’s stay aligned and make this release a success! 🚀
Feel free to reach out if you have questions or need clarification.
Many thanks in advance
Reference