fix: show dapp domain in typed sign V3/V4 Request from for WalletConnect

[joaoloureirop]

Description

When connecting a dapp via WalletConnect, the connection screen shows the correct dapp domain, but the eth_signTypedData (V3/V4) signature request screen showed a random long hex string in the "Request from" field. This caused user confusion and could trigger false deceptive/security warnings.

Root cause: The typed sign V3/V4 confirmation component (InfoSectionOriginAndDetails) read approvalRequest.origin for the "Request from" value. For WalletConnect (and SDK) connections, origin is the permission subject — the pairing topic / channelId hex — not the dapp domain. Other parts of the codebase (e.g. useApprovalInfo, useOriginTrustSignalAlerts) already derive the signature origin from approvalRequest.requestData.meta.url, which holds the dapp's self-reported URL.

Solution: Use approvalRequest.requestData.meta.url for the "Request from" field, falling back to approvalRequest.origin when the metadata URL is absent. This is consistent across connection types

Changelog

CHANGELOG entry: Fixed an issue where signTypedData requests over WalletConnect showed a random hex string instead of the dapp domain in the "Request from" field

Related issues

Fixes: #29072

Manual testing steps

Feature: Signature request origin for WalletConnect

  Scenario: user signs typed data over WalletConnect
    Given a dapp is connected to MetaMask Mobile via WalletConnect
    And the connection screen showed the correct dapp domain

    When the dapp triggers an eth_signTypedData (V3/V4) request
    Then the signature request screen shows the dapp domain in "Request from"
    And no random hex/string is displayed
    And no false deceptive warning is triggered

Screenshots/Recordings

Before

before-wc.mov

After

after-wc.mov

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile 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.

[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.

[mm-token-exchange-service]

PR template — items to address before "Ready for review"

Warnings — informational, address before merging:

• Pre-merge author checklist has only 5 of the required 8 items. Every checklist row must be present and consciously checked — do not delete rows.

See docs/readme/ready-for-review.md for the full Definition of Ready for Review.

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: SmokeConfirmations
• Selected Performance tags: None (no tests recommended)
• Risk Level: medium
• AI Confidence: 92%

click to see 🤖 AI reasoning details

E2E Test Selection:
The PR modifies InfoSectionOriginAndDetails in the typed-sign V3/V4 confirmation flow. The change fixes how the dapp origin is resolved: it now prefers approvalRequest.requestData.meta.url over approvalRequest.origin to correctly display the dapp domain for WalletConnect/SDK connections (where origin is a pairing topic hex, not a human-readable URL). This is a targeted bug fix in the EIP-712 typed data signing confirmation UI. SmokeConfirmations covers typed data signing (EIP-712 V1/V3/V4) and signature request flows, making it the directly relevant tag. No other areas (accounts, network, swap, stake, browser, snaps, etc.) are affected. The companion test file only adds a unit test for the new behavior.

Performance Test Selection:
The change is a small UI fix in the typed sign confirmation info section — it only changes how the origin string is resolved (a nullish coalescing fallback). There is no impact on rendering performance, asset loading, onboarding, login, swaps, or any other performance-measured flow.

View GitHub Actions results