fix(39724): fix QR infinite loader on firefox#40014
Conversation
|
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. |
✨ Files requiring CODEOWNER review ✨🔄 @MetaMask/swaps-engineers (5 files, +692 -5)
|
|
I have read the CLA Document and I hereby sign the CLA |
There was a problem hiding this comment.
Pull request overview
Fixes the infinite loader in Firefox popup → fullscreen transitions for QR hardware wallet bridge/swap signing by persisting enough state to recover the “active quote” and detect completion after the popup state is lost.
Changes:
- Append
requestIdas a query param when navigating to the Awaiting Signatures screen for hardware wallets. - In
AwaitingSignatures, deriverequestIdfrom either Redux (activeQuote) or URL params and detect completion via bridge history; auto-navigate to Activity on completion. - Add a unit test to ensure the hardware wallet route includes the encoded
requestId.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| ui/pages/bridge/hooks/useSubmitBridgeTransaction.ts | Adds requestId query param to the awaiting-signatures navigation URL for HW flows. |
| ui/pages/bridge/hooks/useSubmitBridgeTransaction.test.tsx | Adds a test validating navigation includes the encoded requestId when isHardwareWallet is true. |
| ui/pages/bridge/awaiting-signatures/awaiting-signatures.tsx | Reads requestId from URL as fallback and auto-navigates to Activity once matching bridge history is detected. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| return; | ||
| } | ||
|
|
||
| navigate(`${DEFAULT_ROUTE}?tab=activity`, { |
There was a problem hiding this comment.
The auto-navigation effect can create a back-button loop: after navigating to the home activity tab, pressing Back returns to /awaiting-signatures, which will immediately navigate forward again because hasSubmittedBridgeTx remains true. Consider using navigate(..., { replace: true, state: { stayOnHomePage: true } }) (or otherwise clearing the condition) so the awaiting-signatures route isn’t kept in browser history once completion is detected.
| navigate(`${DEFAULT_ROUTE}?tab=activity`, { | |
| navigate(`${DEFAULT_ROUTE}?tab=activity`, { | |
| replace: true, |
da041ce to
e07e05e
Compare
Builds ready [e07e05e]
UI Startup Metrics (1367 ± 86 ms)
📊 Page Load Benchmark ResultsCurrent Commit: 📄 Localhost MetaMask Test DappSamples: 100 Summary
📈 Detailed Results
Bundle size diffs [🚨 Warning! Bundle size has increased!]
|
e07e05e to
fbf144c
Compare
Builds ready [fbf144c]
UI Startup Metrics (1415 ± 104 ms)
📊 Page Load Benchmark ResultsCurrent Commit: 📄 Localhost MetaMask Test DappSamples: 100 Summary
📈 Detailed Results
Bundle size diffs [🚨 Warning! Bundle size has increased!]
|
|
Tested on Firefox, the original issue is fixed. Adding "qa passed" label. Infinite loader issue is happening for similar scenario: if wrong QR code is used for the signature and the user cancels the transaction. Created separate ticket for this issue #40088 |
… in awaiting-signatures
e858ecd to
74a1c07
Compare
|
Builds ready [74a1c07]
⚡ Performance Benchmarks (1420 ± 108 ms)
🌐 Dapp Page Load BenchmarksCurrent Commit: 📄 Localhost MetaMask Test DappSamples: 100 Summary
📈 Detailed Results
Bundle size diffs [🚨 Warning! Bundle size has increased!]
|
owencraston
left a comment
There was a problem hiding this comment.
I am unable to complete a swap with my keystone. This occurred after a failed swap and then I cleared the transaction history. Before this, I was brought to the get signature screen but I was still unable to complete the swap.
Screen.Recording.2026-02-26.at.3.00.32.PM.mov
|
Thanks for the feedback @owencraston . Using keystone 3 pro, tried to reproduce the issue from your video, but wasn't able to. I have tried few times to swap/bridge different cryptocurrencies on different networks and it works for me. Attaching the video of swapping USDC to ETH on base. Screen.Recording.2026-02-27.at.13.29.25.movHere are other things I noticed:
no.activity.log.mov |
|
@owencraston and the issue you experience is prob outside of this fix, as its on main? Can we go ahead with merging this first? |



Description
This PR fixes an issue where users using QR hardware wallets in popup mode would encounter an infinite loader after successfully signing a bridge/swap transaction. The problem occurred because when the user clicked "Get signature", MetaMask would transition from popup mode to fullscreen mode, causing the popup state to be lost. The
AwaitingSignaturescomponent could no longer track the active quote, leaving users stuck on the loading screen even after the transaction was successfully submitted.The solution:
requestIdas a URL query parameter. This allows the component to track the transaction even when popup state is lost during the popup-to-fullscreen transition.requestIdhas been submitted. It uses therequestIdfrom either the active quote (when available) or from the URL parameters (when popup state is lost).Changelog
CHANGELOG entry: Fixed infinite loader when using QR hardware wallets in popup mode after signing bridge transactions
Related issues
Fixes: #39724
Manual testing steps
Screenshots/Recordings
Before
https://github.com/user-attachments/assets/96988011-5533-4f3d-87d4-988f8ff365f5
User would see infinite loader with "Confirm with your hardware wallet" message even after successful transaction.
After
https://github.com/user-attachments/assets/04372124-46f2-40d6-842d-8e4e4e1dd20c
User is automatically navigated to home page with activity tab showing the completed transaction.
Pre-merge author checklist
Pre-merge reviewer checklist
Note
Medium Risk
Changes bridge/swaps hardware-wallet navigation and auto-redirect logic based on URL params, QR scan state, and bridge history; regressions could mis-route users during two-step flows or on failure/cancel paths.
Overview
Fixes the QR hardware-wallet popup→fullscreen transition getting stuck on the
AwaitingSignaturesloader by persistingrequestIdin the awaiting-signatures URL and using it to recover state when the popup store is lost.Adds
useBridgeTransactionNavigationtoAwaitingSignaturesto auto-navigate tohome?tab=activitywhen the matching bridge tx appears in history, and to also navigate away on QR cancellation/failure while avoiding false positives between approval and bridge steps. UpdatesuseSubmitBridgeTransactionto includerequestIdin the HW-wallet awaiting URL and to usereplace: trueon activity/prepare redirects, with new unit tests and console baseline updates.Written by Cursor Bugbot for commit 74a1c07. This will update automatically on new commits. Configure here.