Borrowed input depends on network and pairing; a drop needs a clear fallback

What it is

Mid-Sidecar, Wi-Fi hiccups. The pen is still on the glass, the computer canvas takes no ink, and the tablet has not returned to its own home screen—two devices, neither in charge. A drop needs a clear fallback. Once the network or pairing the borrow sits on breaks, the source must become itself again, the target must take local input, and both must say “the pen is no longer controlling the computer.” This is not how hard first-time pairing is. Pairing is the door in; fallback is where to stand after the door is kicked open. It is also not who keeps the film after a cast dies. What falls back here is input rights, not playback.

Why it happens

Borrowing hangs the input path on a brittle chain: pairing identity, near-field or LAN, an event channel. Any link dropping stops events from reaching focus, while both sides’ mode bits may still read “borrowing.” If the source still shows a ghost of the computer desktop and cannot reach its own home, that screen is briefly dead. If the target still waits for a remote pen and treats local keys as “not holding the lock,” both sides stall. People are usually mid-stroke at the drop. Fallback has to end or mark the unfinished stroke and hand the lock back to the target’s local input. A “disconnected” banner that does not change mode splits copy from state. Fallback also has to survive false alarms: a short loss should not eject Sidecar; a stable loss should. Hysteresis stops the UI from flapping in the doorway.

Where it stops holding

Wired borrows (a vendor-cable extended display) almost only die when unplugged; fallback can be harder and faster. A target with no local input (a dumb monitor, a display that cannot type) cannot “switch to the local keyboard”; it can only freeze the last frame and demand the source back. A drop during a password or payment should also void that input, so a half password is not left in focus. Pairing revoked by the system (account signed out, Bluetooth turned off) is a vanished condition; fallback copy should name that condition, not a vague “poor network.”

Applying it

• After a stable loss of the borrow channel, return the source to its own desktop within a second, with pen and keys serving only itself. Hand the lock on the target to local keys and mouse, and end any unfinished remote stroke.
• Say the same sentence on both sides: “the tablet is no longer controlling this computer.” Offer one-tap reconnect; do not restart a full pairing wizard unless identity is actually gone.
• Jitter shorter than the hysteresis window should show “signal weak” without changing mode. After a real mode change, do not auto-fight back and forth, or the desktop will flicker.
• Verify by turning Wi-Fi off or walking out of range mid-Sidecar drawing. The tablet must open a local app on its home screen; the computer must keep drawing with its own trackpad; neither side may sit in a ghost. Restore the network: one tap should resume the borrow, not treat the pair as never seen. As a control, a momentary off-and-on must not eject the stroke in progress.

Related

• Within the group: K8.08.1 One device's input (keyboard, stylus) can be borrowed by a nearby device · K8.08.2 Input borrowing needs a clear owner so devices do not fight over input · K8.08.3 Setup and teardown latency of a borrowed connection directly affects usability
• Adjacent: K8.05 Pairing and discovery · K8.04 Screencast and mirroring
• Search terms: Sidecar disconnect · input fallback · borrowed peripheral