feat(hw): QR wallet connection ui wiring#29086
Conversation
Add normalizeReplacementGasFeeParams gas utility, getDeviceIdForAddress helper, QR connection tips, widen setTargetWalletType type, and refactor LedgerTransactionModal to use normalizeReplacementGasFeeParams.
Add QRSigningContext for QR hardware wallet signing state, useQRSigningState hook for managing QR scan request lifecycle, and export from index files.
Add shared utility that runs hardware wallet operations behind the standard readiness + awaiting-confirmation flow. Includes foundation helpers (getDeviceIdForAddress, normalizeReplacementGasFeeParams) as prerequisites.
…lit-4-connection-ui
…split-4-connection-ui
- useDeviceConnectionFlow: skip device discovery for QR wallets, walletType-aware ready handling - HardwareWalletProvider: integrate QRSigningContext, bug fixes for reject ref cleanup and double close - AwaitingConfirmationContent: full QR signing UI with QR code display, scanner, error handling, and scan result verification
|
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. |
…ress The provider now auto-derives the wallet type from the pending operation address, so callers only need to supply the address — not the wallet type. This removes the need for executeHardwareWalletOperation to compute and forward the wallet type explicitly.
…split-4-connection-ui
…ationAddress LedgerSelectAccount uses setTargetWalletType for the Add Hardware Wallet flow, so it must remain in the context interface unchanged.
…split-4-connection-ui
Add pendingOperationAddress state to the provider. The effective wallet type is now derived from targetWalletType OR the pending operation address OR the selected account, keeping setTargetWalletType unchanged for Add Hardware Wallet flows.
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #29086 +/- ##
==========================================
+ Coverage 82.19% 82.26% +0.07%
==========================================
Files 5069 5097 +28
Lines 133674 134430 +756
Branches 29969 30171 +202
==========================================
+ Hits 109870 110594 +724
- Misses 16334 16340 +6
- Partials 7470 7496 +26 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…on' into feat/mul-1507-split-4-connection-ui
Ensure the awaiting confirmation QR test injects `setRequestCompleted` through `QRSigningContext` so the assertion covers the real completion path instead of an unused prop. Made-with: Cursor
Read the signing wallet type from shared hardware wallet refs so ensureDeviceReady can select the correct adapter before React finishes re-rendering. Add regression coverage for the pending operation wallet type flow and the provider wallet type update. Made-with: Cursor
1032ef1 to
f63f233
Compare
AI PR Analysis🚫 Merge safe: false | 🟠 Risk: high
AI analysis did not complete. Manual review recommended. |
There was a problem hiding this comment.
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 4e5a5f6. Configure here.
🔍 Smart E2E Test Selection
click to see 🤖 AI reasoning detailsE2E Test Selection:
Why SmokeAccounts: The tag description explicitly covers "adding QR-based hardware wallet accounts" - this is the most directly relevant E2E coverage for hardware wallet changes. Why SmokeConfirmations: The Risk factors:
Confidence is 72 because: while the changes are clearly scoped to hardware wallet functionality, there are no dedicated hardware wallet E2E tests found. The selected tags (SmokeAccounts, SmokeConfirmations) provide the closest coverage but may not directly exercise the QR hardware wallet paths. Performance Test Selection: |
|
|
✅ E2E Fixture Validation — Schema is up to date |




Description
This PR is split 4 of the QR hardware context merger with the hardware wallet context. It adds a
useQRSigningStatehook andQRSigningContextto manage pending scan requests from Redux, track request completion, and provide cancellation via the QR keyring scanner. TheuseDeviceConnectionFlowhook is extended to skip device discovery for QR wallets and resolve readiness directly so the caller can transition straight to awaiting-confirmation. Finally,AwaitingConfirmationContentis expanded to render wallet-type-specific content (Ledger vs QR), including QR scanning instructions, animated connection tips, and a reject button wired to the signing rejection callback.Changelog
CHANGELOG entry: Merges QR Signing Context with Hardware Wallet Context
Related issues
Related: https://consensyssoftware.atlassian.net/browse/MUL-1741?atlOrigin=eyJpIjoiMDdkOGRkYmYwMTdlNDRhMWEwMjNjMzM2ZGZmZDg5NDIiLCJwIjoiaiJ9
Manual testing steps
Screenshots/Recordings
Before
After
Pre-merge author checklist
Performance checks (if applicable)
trace()for usage andaddTokenfor an exampleFor performance guidelines and tooling, see the Performance Guide.
Pre-merge reviewer checklist
Note
Medium Risk
Touches core hardware-wallet connection/readiness flow and adds QR-specific signing UX, which could regress non-QR device connection states or error/retry behavior if edge cases are missed.
Overview
Adds QR hardware-wallet signing support end-to-end by introducing
QRSigningContext/useQRSigningState(Redux-backed) and wrappingHardwareWalletProviderchildren + bottom sheet with this context.Updates the connection flow to support QR wallets: derives an effective wallet type from a pending-operation address, prefers a
pendingOperationWalletTypeRefbefore React renders catch up, skips device discovery whenrequiresDeviceDiscoveryis false, and forHardwareWalletType.Qrresolves readiness directly (avoiding the intermediate "Ready/success" modal).Expands
AwaitingConfirmationContentwith a QR-specific UI (animated QR, scanner modal, cancel/reject wiring, mismatched-request-id handling with analytics) while keeping the existing Ledger/Lattice spinner view. Tests are significantly extended/updated to cover pending wallet-type derivation, QR scan success/error paths, and updated retry/close semantics after signing errors.Reviewed by Cursor Bugbot for commit 9bf7d8c. Bugbot is set up for automated code reviews on this repo. Configure here.