refactor: connection Flow to use CAIP25 Permission format

[ffmcgee725]

For part of our collaboration with the Snaps team to enable Non EVM multichain API we are refactoring the connection flow UI.

The first step to enable this to modify what the connection confirmation UI components receive from the ApprovalController.
Currently they receive an object like this:

{
    "eth_accounts": {
        "caveats": [
            {
                "type": "restrictReturnedAccounts",
                "value": []
            }
        ]
    },
    "endowment:permitted-chains": {
        "caveats": [
            {
                "type": "restrictNetworkSwitching",
                "value": []
            }
        ]
    }
}

Basically the params for a wallet_requestPermission request.

We want to change this so that instead they receive (and know how to interpret) a CAIP25 formatted request like:

{
    "eip155:1": {
        "accounts": []  // there may be accounts here but often will not be
    },
    "eip155:10": {
        "accounts": []
    },
}

Description

Related issues

Fixes:

Manual testing steps

1. Send the following request

await window.ethereum.request({
 "method": "wallet_requestPermissions",
 "params": [
  {
    
    "eth_accounts": {
        "caveats": [
            {
                "type": "restrictReturnedAccounts",
                "value": []
            }
        ]
    },
    "endowment:permitted-chains": {
        "caveats": [
            {
                "type": "restrictNetworkSwitching",
                "value": []
            }
        ]
    }
  }
],
});



2. Wallet extension UI should prompt user to give permissions to accounts / chains and edit if desired or confirm to proceed.

Screenshots/Recordings

Screen.Recording.2025-01-23.at.17.18.17.mov

NOTE: Don't mind different screens in the UI, this vid is outdated and all UI screens are same as main branch

Before

After

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Extension Coding Standards.
• 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 format if applicable
• I’ve applied the right labels on the PR (see labeling guidelines). 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.

[adonesky1]

[nit] - I think parse maybe is a confusing word for this.

maybe just keep it pretty generic/straightforward:

Suggested change

	export function parseCaip25PermissionsResponse(
	export function getApprovedSessionsScopes(

[ffmcgee725]

resolved in ecad6ee

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[adonesky1]

LGTM

[metamaskbot]

Builds ready [ae0bdb4]

• builds: chrome, firefox
• builds (flask): chrome, firefox
• builds (MMI): chrome
• builds (test): chrome, firefox
• builds (test-flask): chrome, firefox
• build viz: Build System
• mv3: Bundle Size Stats
• mv2: E2e Actions Stats
• storybook: Storybook
• typescript migration: Dashboard
• all artifacts
• bundle viz:

  • background: 0, 1, 2, 3, 4, 5, 6, 7
  • common: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
  • ui: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
  • content-script: 0
  • offscreen: 0

Page Load Metrics (1747 ± 70 ms)

Platform	Page	Metric	Min (ms)	Max (ms)	Average (ms)	StandardDeviation (ms)	MarginOfError (ms)
Chrome	Home	firstPaint	1541	2120	1744	145	69
		domContentLoaded	1531	2063	1717	136	65
		load	1543	2118	1747	145	70
		domInteractive	24	206	44	39	19
		backgroundConnect	9	87	27	21	10
		firstReactRender	17	168	48	37	18
		getState	5	61	20	21	10
		initialActions	0	1	0	0	0
		loadScripts	1100	1531	1271	113	54
		setupStore	8	61	17	17	8
		uiStartup	1713	2481	2034	207	99

Bundle size diffs [🚨 Warning! Bundle size has increased!]

• background: 490 Bytes (0.01%)
• ui: 1.24 KiB (0.02%)
• common: -409 Bytes (-0.00%)

[metamaskbot]

Builds ready [bfccd6e]

• builds: chrome, firefox
• builds (flask): chrome, firefox
• builds (MMI): chrome
• builds (test): chrome, firefox
• builds (test-flask): chrome, firefox
• build viz: Build System
• mv3: Bundle Size Stats
• mv2: E2e Actions Stats
• storybook: Storybook
• typescript migration: Dashboard
• all artifacts
• bundle viz:

  • background: 0, 1, 2, 3, 4, 5, 6, 7
  • common: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
  • ui: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
  • content-script: 0
  • offscreen: 0

Page Load Metrics (1666 ± 78 ms)

Platform	Page	Metric	Min (ms)	Max (ms)	Average (ms)	StandardDeviation (ms)	MarginOfError (ms)
Chrome	Home	firstPaint	466	2063	1607	309	148
		domContentLoaded	1486	2003	1643	156	75
		load	1497	2057	1666	163	78
		domInteractive	24	87	35	15	7
		backgroundConnect	8	56	28	18	9
		firstReactRender	15	98	47	27	13
		getState	4	53	12	13	6
		initialActions	0	1	0	0	0
		loadScripts	1057	1494	1190	137	66
		setupStore	7	52	12	9	4
		uiStartup	1693	2329	1906	185	89

Bundle size diffs [🚨 Warning! Bundle size has increased!]

• background: 490 Bytes (0.01%)
• ui: 1.13 KiB (0.01%)
• common: -259 Bytes (-0.00%)

[metamaskbot]

Builds ready [80611dc]

• builds: chrome, firefox
• builds (flask): chrome, firefox
• builds (MMI): chrome
• builds (test): chrome, firefox
• builds (test-flask): chrome, firefox
• build viz: Build System
• mv3: Bundle Size Stats
• mv2: E2e Actions Stats
• storybook: Storybook
• typescript migration: Dashboard
• all artifacts
• bundle viz:

  • background: 0, 1, 2, 3, 4, 5, 6, 7
  • common: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
  • ui: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
  • content-script: 0
  • offscreen: 0

Page Load Metrics (1643 ± 64 ms)

Platform	Page	Metric	Min (ms)	Max (ms)	Average (ms)	StandardDeviation (ms)	MarginOfError (ms)
Chrome	Home	firstPaint	222	1881	1361	564	271
		domContentLoaded	1410	1861	1621	129	62
		load	1418	1867	1643	134	64
		domInteractive	23	79	39	17	8
		backgroundConnect	7	66	25	18	9
		firstReactRender	15	78	34	25	12
		getState	4	56	14	17	8
		initialActions	0	1	0	0	0
		loadScripts	1003	1366	1178	108	52
		setupStore	7	87	23	25	12
		uiStartup	1608	2292	1938	199	96

Bundle size diffs [🚨 Warning! Bundle size has increased!]

• background: 490 Bytes (0.01%)
• ui: 1.13 KiB (0.01%)
• common: -259 Bytes (-0.00%)

[ffmcgee725]

To make sure we render the proper UI on wallet_switchEthereumChain request, we add an edge case.

Fortunately for us, this code is not triggered on:

{
 "method": "wallet_requestPermissions",
 "params": [
  {
    
    "eth_accounts": {
        "caveats": [
            {
                "type": "restrictReturnedAccounts",
                "value": []
            }
        ]
    },
    "endowment:permitted-chains": {
        "caveats": [
            {
                "type": "restrictNetworkSwitching",
                "value": ["0x1"]
            }
        ]
    }
  }
],

So we are safeguarded that the proper UI will render on every covered case (no UI changes after the refactor, all e2e tests make sure of that ✅ )

[ffmcgee725]

Here I decided to check state object to get latest pending permission from current origin, so we can see the method to see if wallet_switchEthereumChain was used to make the call.

This way, if it was used to make the call, we are sure isRequestingAccounts (perhaps this variable name should be re-thinked...) is evaluated to false.
So, downstream on ui/pages/permissions-connect/permissions-connect.component.js we make sure to trigger

if (history.location.pathname === connectPath && !isRequestingAccounts) {
     /* `isRequestingAccounts` is now false, so negating it becomes true and we enter the switch case */
      switch (requestType) {
        case 'wallet_installSnap':
          history.replace(snapInstallPath);
          break;
        case 'wallet_updateSnap':
          history.replace(snapUpdatePath);
          break;
        case 'wallet_installSnapResult':
          history.replace(snapResultPath);
          break;
        case 'wallet_connectSnaps':
          history.replace(snapsConnectPath);
          break;
        default:
          history.replace(confirmPermissionPath); /* <---- We want the flow to come here to render the proper UI */
      }

This seems to be a consistent way of making UI rendering behaviour stay the same after the refactor. But I'm open to discussion if you guys have a better approach to solving this problem.