Repository navigation
fix(wallet): open Send for silent payment addresses scanned on home - #199
Merged
Merged
Conversation
There was a problem hiding this comment.
🟡 Changes recommended
Address normalization drops the previously accepted bitcoin=<address> format.
1 open finding
What changed in this PR
Adds silent-payment address routing and clearer scan errors on the wallet home screen.
Changes:
- Recognizes silent-payment addresses on the active network.
- Distinguishes wrong-network and unrecognized inputs.
- Adds unit and end-to-end coverage.
| File | Description |
|---|---|
class/deeplink-schema-match.ts |
Adds network-aware routing results. |
screen/wallets/WalletsList.tsx |
Routes scans or displays errors. |
loc/en.json |
Adds scan error messages. |
tests/unit/deeplink-schema-match.test.js |
Tests routing and network handling. |
tests/e2e/05-send.spec.js |
Tests home-screen scanning flows. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
theanmolsharma
requested changes
Oct 13, 2026
The contacts spec copied its strings out of loc/en.json, so a copy edit there only showed up as a waitFor timeout. en.json is plain data, so the spec now imports it directly. The silent payment addresses move into tests/fixtures so other specs and unit tests can use the same ones.
The app has no widget, and nothing passes navigationRouteFor a context, so the shroud://widget?action= branch could never route anywhere. The branch, isWidgetAction and the unused context parameter are removed.
A setelectrumserver link with a malformed % escape threw from decodeURIComponent, and url.parse can throw on its own for some inputs. A link with no server, or one that didn't parse, still opened Electrum settings, which then did nothing with it. The decode is guarded inside getServerFromSetElectrumServerAction, the url.parse check becomes a prefix check, and the link only routes when it carries a server.
Scanning or pasting something home couldn't route did nothing, with no feedback. navigationRouteFor called back only on success. destinationFor replaces it and returns where the input should open, or that it's unrecognized. Home shows an error alert for unrecognized input and does the navigation itself, passing the wallet ID SendDetails requires, so the @ts-ignore on the spread route goes away.
Scanned input had its scheme cleaned up in three places, three different ways. The route rewrote the first :// anywhere in the string, so a label such as http://example.com lost its slashes. bip21decode only rewrote three exact spellings, so Bitcoin://addr decoded to the address //addr. A single helper now trims the input, unwraps shroud:bitcoin: and rewrites a leading bitcoin: or bitcoin:// in any case to bitcoin:. Routing and bip21decode both use it, so Send always receives a lowercase bitcoin: URI. The address is extracted once and checked against a given network, replacing isBitcoinAddress. The old bitcoin= prefix is no longer stripped. It isn't BIP21, and an input such as bitcoin=<address> opened Send with that whole string as the address, so it is now reported as unrecognized.
Scanning or pasting a silent payment address on home reported it as unrecognized, because only addresses bitcoinjs can parse counted as payable. They now open Send prefilled, bare or inside a bitcoin: URI. An address that is valid on another network, such as a signet address while the wallet is on mainnet, gets its own error naming the active network instead of the generic one. A bitcoin: URI with only an sp= parameter (BIP-321) is still unrecognized and left as a TODO.
getClipboardContent returns undefined when the clipboard holds no text or reading it is turned off. undefined?.trim().length === 0 is false, so Paste was offered anyway and tapping it did nothing.
chaitika
force-pushed
the
fix/home-sp-scan
branch
from
October 14, 2026 08:08
357d295 to
f3dde43
Compare
theanmolsharma
approved these changes
Oct 14, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Fixes #197.
Changes
bitcoin:link.navigationRouteForis replaced bydestinationFor, which returns{ send } | { electrumServer } | { error }. Home does the navigation itself and passes thewalletIDSendDetails needs, so the@ts-ignoreis gone.bitcoin:scheme is cleaned up in one place, used by both routing andbip21decode. Labels containing://and mixed-caseBitcoin://now parse correctly.isBitcoinAddressis replaced by private helpers.bitcoin=prefix: no longer accepted. It isn't BIP21, and it used to open Send with the whole string as the address.setelectrumserverlinks: a link with no usable server or a malformed%escape returns unrecognized instead of throwing or opening empty settings.url.parseis replaced by a prefix check.contextparameter are removed.tests/fixtures/addresses.js, and07-contactsreads its strings fromloc/en.json.bitcoin:?sp=links are still unrecognized; see Support BIP-321 sp= payment links #202.