Skip to content

fix(contacts): tell the user when a scanned QR carries no address [PERA-4746] - #1110

Draft
yasin-ce wants to merge 1 commit into
mainfrom
yasince/fix/PERA-4746
Draft

fix(contacts): tell the user when a scanned QR carries no address [PERA-4746]#1110
yasin-ce wants to merge 1 commit into
mainfrom
yasince/fix/PERA-4746

Conversation

@yasin-ce

Copy link
Copy Markdown
Collaborator

Description

Scanning a wrong-context QR into an address field (a WalletConnect code is the common one) closed the scanner and left the field empty with nothing said, so it was indistinguishable from a scan that never registered.

  • Address-field scanners now show a readable "Invalid QR Code" error, matching what the mnemonic-import scanner already does.
  • Both scan paths had their own copy of the silent drop — AddressEntryField and ContactForm — so the rule now lives once in useScannedAddress, and both adopt it. AddressSearchInput and WatchAccountScreen inherit it through AddressEntryField.

Related Issues

Checklist

  • Have you tested your changes locally?
  • Have you reviewed the code for any potential issues?
  • Have you documented any necessary changes in the project's documentation?
  • Have you added any necessary tests for your changes?
  • Have you updated any relevant dependencies?

Additional Notes

The dismiss has to happen before the toast, and that is the subtle part. errorToast passes no notifier, so useToast falls back to the global Notifier, which renders in the root tree — the tree useQRScannerView's own docstring describes as obscured by the scanner's native Modal while it is open. Toasting first would schedule the notification behind the Modal and leave whether the user sees it up to dismiss-animation timing. Both callers now dismiss first, mirroring useImportAccountScreen, and a test asserts isVisible === false at the moment the resolver runs so the ordering can't regress silently.

Why the hook sits in @hooks/ rather than beside AddressEntryField. It is shared by two components, and putting it under one of them meant ContactForm deep-importing past that component's barrel. Keeping extractAddressFromScannedUrl in the component file also created a real import cycle (component → hook → component), which is why the util moved with it. Its existing tests moved to the new spec, along with two new cases for the hook.

An earlier revision of this branch toasted before dismissing and kept the hook inside the component folder; both were caught in review and are fixed here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant