Show a handoff screen instead of a QR code on a handheld - #4
Merged
Conversation
Opening the site on a phone produced a QR code with the instruction to scan it with a phone — a dead end, since the device meant to scan it is the one already displaying it. The previous attempt at this was a grey footnote appended below the card, so on a phone it sat under a full-size QR code and was never seen. A handheld that arrives without a pairing link now gets a screen naming the address to open on the computer, and no session is created: one nobody can pair to only burns the per-IP create limit. The role is still decided by the pairing fragment alone. The device query chooses which screen the receiver opens on, never who the page becomes — a phone that arrives *with* a pairing link still goes straight to the scanner. Because the guess can be wrong (a tablet at a counter, desktop mode, an odd viewport) the screen carries a one-tap escape hatch, and a stored session is honoured without asking again. Verified in headless Chromium with device emulation, since `pointer: coarse` cannot be exercised by curl and both recent bugs here came from never rendering the page: iPhone 13 with no link gets the handoff and no QR; desktop still gets a session and a QR; iPhone 13 with a pairing link still routes to the scanner. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
2 participants
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.
Opening the site on a phone produced a QR code with the instruction to scan it with a phone — a dead end, since the device meant to scan it is the one already displaying it.
The previous attempt at this was a grey
.footnoteappended below the card, so on a phone it sat underneath a full-size QR code and was never seen. Being present in the bundle is not the same as being visible.What changes
A handheld arriving without a pairing link now gets a screen naming the address to open on the computer, and no session is created — one nobody can pair to only burns the per-IP create limit.
The role is still decided by the pairing fragment alone. The device query chooses which screen the receiver opens on, never who the page becomes: a phone that arrives with a pairing link still goes straight to the scanner. Because the guess can be wrong (a tablet at a counter, desktop mode, an odd viewport) the screen carries a one-tap escape hatch, and a stored session is honoured without asking again.
Verification
pointer: coarsecannot be exercised by curl, and both recent bugs here came from never rendering the page — so this was checked in headless Chromium with device emulation:/p#s=…&t=…64 tests still pass.
🤖 Generated with Claude Code