Description

Adds the ability to edit gas (network fee) from the cancel/speed up modal before confirming. Users can tap the network fee row to open the gas fee modal, adjust gas, then confirm cancel or speed up. A new context allows the gas modal to operate on the cancel/speed up transaction instead of only the current approval request.

Changes

Cancel/Speed up modal

• Edit network fee: When the cancel/speed up modal is open, the network fee row shows an edit icon and is tappable. Tapping opens the existing gas fee modal so the user can change gas before confirming.
• Seeding bump params: When the modal opens, the transaction is updated with suggested bump params via getBumpParamsForCancelSpeedup and updateTransactionGasFees, so the gas modal shows the recommended values when the user taps edit.
• Single source of truth: useCancelSpeedupGas now takes txId and reads the transaction from the store. Gas edits from the gas modal (via updateTransactionGasFees) are reflected in the cancel/speed up modal.

Gas fee modal transaction context

• New context: GasFeeModalTransactionProvider and useGasFeeModalTransaction let the gas modal work with a specific transaction id (e.g. the cancel/speed up tx) instead of only the approval request.
• Metadata hook: useTransactionMetadataRequest uses the context; when transactionId is set (e.g. from cancel/speed up), it uses that id for transaction metadata instead of the approval request id.

useCancelSpeedupGas refactor

• API: Input changed from { tx, isCancel } to { txId }. Hook reads the transaction with selectTransactionMetadataById(state, txId).
• Helper: getBumpParamsForCancelSpeedup(tx, isCancel, gasFeeEstimates) is exported and used to compute bump params when the cancel/speed up modal opens.
• Display: Hook returns params derived from the transaction in the store so the modal reflects any gas changes made in the gas modal.

Cancel / Speed Up + Edit Gas — Flow (Happy Path)

One-line: Pending Tx → Open modal (seed bump) → [Confirm or Edit gas → Confirm] → Submit.

flowchart TB
  A[Pending Tx] --> B[Open Cancel/Speed Up Modal]
  B --> C[Seed bump params]
  C --> D[Show fee, Edit, Confirm]
  D --> E[Confirm]
  D --> F[Edit]
  F --> G[Gas Modal]
  G --> H[Apply]
  H --> D
  E --> I[Submit speed up/cancel]

Legend

Data flow (compact)

• Modal → store: On open, bump params written to tx via updateTransactionGasFees.
• Gas modal → store: User changes applied via same util; useCancelSpeedupGas reads tx from store, so fee row updates.
• Confirm: onConfirm(paramsForController) uses whatever is on the tx (default bump or user-edited).

Changelog

CHANGELOG entry: Added edit gas from cancel/speed up modal: users can tap the network fee row to open the gas fee modal and adjust gas before confirming cancel or speed up

Related issues

Fixes: https://github.com/MetaMask/mobile-planning/issues/2419 https://consensyssoftware.atlassian.net/browse/CONF-1007

Manual testing steps

Scenario: User opens cancel/speed up modal and sees editable network fee
  Given the user has a pending transaction
  And the user opens the cancel or speed up modal for that transaction
  Then the modal shows the current network fee (native and fiat)
  And the network fee row shows an edit icon
  And the network fee row is tappable

Scenario: User edits gas from cancel/speed up modal
  Given the user has a pending transaction
  And the user has opened the cancel or speed up modal
  When the user taps the network fee row (or the edit icon)
  Then the gas fee modal opens
  And the gas fee modal shows the suggested bump values for that transaction
  When the user changes gas (e.g. max fee or priority fee) in the gas modal
  And the user confirms or applies in the gas modal
  Then the gas modal closes
  And the cancel/speed up modal shows the updated network fee
  When the user taps the confirm button in the cancel/speed up modal
  Then the cancel or speed up is submitted with the user-edited gas

Screenshots/Recordings

Before

After

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.