fix: tempo disable confirm button until gas autoselect

[maxime-oe]

Description

The goal of the change is to prevent a premature "enablement" for the Confirm button when a transaction is loading. There are pre-existing race conditions that allowed users to confirm a transaction before everything is fully loaded. Those conditions could make the tx skip gasless flows, falling back to native token for gas payment.

The impact is bigger on Tempo because using a native token is not an option (there is no native token on Tempo), which means that such race condition will always result in a failed tx (the tx won't be sent to the RPC or relayer).

The changes solve the race conditions cases, as well as adds some extra conditions for the loading when on a chain that has no native token.

Changelog

CHANGELOG entry: add new isGaslessLoading guard to Confirmation button - consistently with Extension.
CHANGELOG entry: useIsGaslessSupported to use useQuery instead of useAsync to avoid race conditions.

Related issues

Fixes: https://consensyssoftware.atlassian.net/browse/NEB-944?atlOrigin=eyJpIjoiYWFiY2U0NjU1ZjEzNGNmODlmOTZkNTQwNzM4N2MxMTUiLCJwIjoiaiJ9

Manual testing steps

Repeating instructions shared for Extension since Mobile flow will be very similar (just "tap" instead of click ;))

• On Tempo mainnet, find pathUSD and click on "Send".
• Set amount to 0.01 and select the account to send to (any account).
• As soon as you clicked on the recipient account, start "spam clicking" on "Confirm" or the location where you know "Confirm" will appear.

What should be observed is that despite spam-clicking, it should not be possible to "Confirm" the transaction "too soon" and it should always succeed no matter how "early" you click on "Confirm".

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.

---

Note

Medium Risk
Changes confirmation disablement logic around gasless support and switches gasless eligibility checks to React Query; could affect when users can confirm transactions and may introduce edge-case loading states on chains without native gas.

Overview
Prevents premature transaction confirmation by disabling the Confirm button while gasless support/fee-token auto-selection is still loading (Footer now gates on new useIsGaslessLoading in addition to transaction pay loading).

Adds useIsGaslessLoading to detect gasless-related loading (including Tempo-style no native token cases and mismatched selectedGasFeeToken), and refactors useIsGaslessSupported to use React Query (useQuery) for relay support checks to reduce race conditions.

Test infrastructure is updated to wrap renderWithProvider/renderHookWithProvider with a QueryClientProvider, and relevant tests are adjusted/mocked accordingly (including new unit tests for useIsGaslessLoading).

^{Reviewed by Cursor Bugbot for commit 164017b. Bugbot is set up for automated code reviews on this repo. Configure here.}

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

[codecov-commenter]

Codecov Report

❌ Patch coverage is 93.10345% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.15%. Comparing base (9f195d0) to head (d21da8d).
⚠️ Report is 73 commits behind head on main.

Files with missing lines	Patch %	Lines
...ews/confirmations/hooks/gas/useIsGaslessLoading.ts	90.90%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##             main   #28722     +/-   ##
=========================================
  Coverage   82.14%   82.15%             
=========================================
  Files        4949     5000     +51     
  Lines      130070   131267   +1197     
  Branches    29004    29289    +285     
=========================================
+ Hits       106851   107840    +989     
- Misses      15923    16087    +164     
- Partials     7296     7340     +44     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 519d6d7. Configure here.}

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: SmokeConfirmations, SmokeTrade, SmokePredictions, SmokePerps
• Selected Performance tags: None (no tests recommended)
• Risk Level: medium
• AI Confidence: 85%

click to see 🤖 AI reasoning details

E2E Test Selection:

The changes in this PR are focused on the confirmations system with gasless transaction support:

1. footer.tsx - The confirmation footer now disables the confirm button when isGaslessLoading is true. This affects ALL confirmation types (send, swap, signatures, contract interactions). The footer is a shared component across all confirmation flows.

2. useIsGaslessLoading.ts (new hook) - Determines if gasless fee token loading is in progress. This is used to prevent premature confirmation submission when gasless fee tokens haven't loaded yet (relevant for EIP-7702 and Smart Transactions).

3. useIsGaslessSupported.ts - Refactored from useAsyncResult to @tanstack/react-query's useQuery. This changes the async state management for relay support checks. The pending state behavior may differ slightly between the two implementations, which could affect when the confirm button is disabled.

4. renderWithProvider.tsx - Added QueryClientProvider wrapper to the shared test utility. This is a test infrastructure change that enables @tanstack/react-query hooks to work in all tests using renderWithProvider. This is a positive change but could theoretically affect test behavior if any tests were previously mocking @tanstack/react-query globally (as seen in PredictBalance.test.tsx which removed its manual mock).

Tag Selection Rationale:

• SmokeConfirmations: Primary target - the footer component and gasless loading hooks directly affect all confirmation flows including send, swap, signatures, EIP-7702 batch transactions, and gas fee token payments.
• SmokeTrade: Swap and bridge flows go through confirmations. The footer change affects the confirm button in swap confirmation screens. Per tag description, when selecting SmokeTrade for swap/bridge, also select SmokeConfirmations.
• SmokePredictions: The PredictBalance and PredictPositionsHeader test files were modified to remove manual @tanstack/react-query mocks (now handled by renderWithProvider). Predictions involve on-chain transactions that go through confirmations.
• SmokePerps: The Perps Add Funds flow involves on-chain transactions through confirmations. Also, Perps is a section inside Trending (SmokeWalletPlatform), but the direct impact is through confirmations.

Not selected:

• SmokeWalletPlatform: No direct changes to wallet platform features; the Predict test changes are minor mock cleanup
• SmokeAccounts, SmokeIdentity, SmokeNetworkAbstractions, SmokeNetworkExpansion, SmokeMultiChainAPI, SmokeBrowser, SmokeRamps, SmokeCard, SmokeSeedlessOnboarding, FlaskBuildTests: No relevant changes to these areas

Performance Test Selection:
The changes are focused on gasless loading state management in the confirmation footer and a refactor of useIsGaslessSupported from useAsyncResult to react-query. These are logic/state changes rather than rendering performance changes. The renderWithProvider test utility change adds QueryClientProvider but this is test-only infrastructure. No performance-sensitive code paths (account lists, app startup, login, asset loading, swap execution timing) are affected.

View GitHub Actions results

[github-actions]

✅ E2E Fixture Validation — Schema is up to date
12 value mismatches detected (expected — fixture represents an existing user).
View details

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[nikolastoimenovski-consensys]

Tested locally, fixed, adding the "qa passed" label.

[matthewwalsh0]

What's the benefit of switching to useQuery here? Is this required?

Any caching should be handled by the server and browser / os based on caching headers.

[maxime-oe]

The problem was that useAsync was not properly managing the { enabled } mode with the shouldCheck7702Eligibility && Boolean(chainId) condition. The hook go through cycles where chainId has some value, then hasn't, then has some value again.
I first tried to change useAsync so it would behave more that useQuery, then decided it was too risky cause useAsync is used in multiple places.
Then I tried to wrap the shouldCheck7702Eligibility && Boolean(chainId) condition manually in useIsGaslessSupported but I kept getting race conditions.

useQuery on the other hand worked immediately and exacted as one would expect when reading the code. So I went for it - after 1/2 hrs of die and retry.

[matthewwalsh0]

Then the deeper issue is why the chainId is ever not set for an active transaction?

It should be available on the transaction meta for its entire lifetime, why doesn't the same behaviour happen in extension?

[maxime-oe]

Then the deeper issue is why the chainId is ever not set for an active transaction?

I think this never happens, but that transactionMeta is not always set. Maybe I was wrong about that one re-becoming undefined but at least one variable was doing back-and-forth - I should have noted this one.

I'll start over and try to redo it but it might not be as bullet-proof as the useQuery solution. The current solutions works (as opposed as before). It is just not the original code.

[matthewwalsh0]

Is this needed? If not, does this file need changing at all?

[maxime-oe]

No I can roll back those two lines if reducing the LoCs / amount of changes is import. I still want to fight for my useQuery though, unless you see a clear alternative: Only one I'd see otherwise is making the hook more complex by not using either useQuery or useAsync.

[matthewwalsh0]

Does this have larger implications if mobile wasn't previously disabled while gas station was loading?

[maxime-oe]

Yes it might actually feel less flaky on slower devices - the "Confirm" button blinks much more on Mobile than on Extension, maybe due to isTransactionValueUpdating. If isGaslessLoading remains "true" longer than the time for isTransactionValueUpdating to go true then false for example.
But on Tempo this "blinking" is more than UX gimmick, it makes the tx fail if the user taps during one of those blinks.

[matthewwalsh0]

We wouldn't need any changes in Predict code if we didn't change to useQuery?

[maxime-oe]

No but I couldn't find any clean alternative.
I modified those 2 test files after making the changes in renderWithProvider.tsx

[maxime-oe]

Dropped and replaced by #29188