[Bug]: Permissions 7715 - Metrics - New Confirmation page event is sent with incorrect chain id

[seaona]

Describe the bug

New Confirmation page event is sent with incorrect chain id. Ie in this case, I'm triggering Permissions for Sepolia, but the chain_id property in the New Confirmation PAge event is set to 0x1

Expected behavior

• We should set the correct chain id
• It seems we could add more properties here, to get a bit more insights, like the type of permission

Screenshots/Recordings

metrics-chain-id.mov

Steps to reproduce

1. Open network requests
2. Trigger a Grant Permission on Sepolia
3. See event is set to chain id 0x1

Error messages or log output

Detection stage

In production (default)

Version

flask

Build type

None

Browser

Chrome

Operating system

MacOS

Hardware wallet

No response

Additional context

No response

Severity

No response

[dan437]

@cursor Analyze this MetaMask issue and provide:

1. Problem: What's broken (2-3 sentences)
2. Root Cause: 1-2 likely causes based on evidence
3. Target Repo(s): Which repo needs the fix (this repo/core/transaction-controller/other controllers in the core repo)
4. Solutions: 2-3 approaches with pros/cons, recommend the best one
5. Impact: Severity + complexity estimate

[cursor]

Create PR

Based on my analysis of the codebase, here's a comprehensive breakdown of the issue:

1. Problem

When users trigger a "Grant Permission" request for a specific network (e.g., Sepolia), the "New Confirmation Page" metrics event incorrectly reports the chain_id as 0x1 (mainnet) instead of the actual network's chain ID. This happens because the metrics system uses the globally selected network's chain ID rather than extracting the chain ID from the permission request itself, causing inaccurate analytics data about which networks users are granting permissions for.

2. Root Cause

The issue is in /workspace/app/scripts/controllers/metametrics-controller.ts:

    let chainId;
    if (
      properties &&
      'chain_id_caip' in properties &&
      typeof properties.chain_id_caip === 'string'
    ) {
      chainId = null;
    } else if (
      properties &&
      'chain_id' in properties &&
      typeof properties.chain_id === 'string'
    ) {
      chainId = properties.chain_id;
    } else {
      chainId = this.chainId;
    }

The #buildEventPayload method falls back to this.chainId (line 1328) when no chain_id is provided in event properties. This this.chainId is set from NetworkController's selected network (lines 484, 541), which represents the user's current wallet network, not the network in the permission request. Since the page view tracking in /workspace/ui/contexts/metametrics.js (line 189) doesn't pass a chain_id property, it defaults to the wrong value for permission flows.

3. Target Repo(s)

This repository (metamask-extension) - The fix needs to be in the UI layer where page view metrics are tracked.

4. Solutions

Option A: Extract chain ID from approval request data (RECOMMENDED)

• Approach: Modify the page tracking logic to detect permission-related routes and extract the chain ID from the approval request's CAIP-25 caveat value
• Pros:
  • Accurate chain ID for permission requests
  • Can be extended to track additional permission properties (e.g., permission type, scopes)
  • Aligns with the PR's suggestion to add more insights
• Cons:
  • Requires accessing Redux state in the metrics context
  • Moderate complexity
• Implementation: Update /workspace/ui/contexts/metametrics.js around line 189 to check if the current route is a permission confirmation, fetch the approval request, and extract the relevant chain IDs from the CAIP-25 caveat

Option B: Pass chain ID from ConfirmationPage component

• Approach: Have confirmation page components explicitly pass chain_id as a property when tracking page views
• Pros: Simpler, more explicit
• Cons:
  • Requires changes to multiple confirmation components
  • Doesn't solve the issue at the route-level tracking point
  • Less maintainable

Option C: Add chain_id to route tracking metadata

• Approach: Extend the routes configuration to dynamically determine chain_id based on route parameters
• Pros: Centralized solution
• Cons:
  • Complex routing logic
  • May not have access to approval data at route level

Recommendation: Option A provides the most accurate tracking while allowing for future enhancements like tracking permission types and scopes as mentioned in the issue.

5. Impact

• Severity: Medium - Affects analytics accuracy but not functionality. Incorrect metrics can lead to poor product decisions about network adoption and permission flows.
• Complexity: Medium - Requires careful extraction of chain IDs from CAIP-25 permission structures and proper handling of multi-chain permission requests (a permission request can span multiple networks).

---

 

_{Learn more about Cursor Agents}