Jon Kinney 07cc40f6ba fix(input-capture): don't drop events after TCC Accessibility revocation ...

When the user revokes Accessibility in System Settings while Lan
Mouse is in a captured session (cursor on a remote client), the
session-level event tap receives `TapDisabledByUserInput`. The
previous flow was:

  1. Callback sends `ProducerEvent::EventTapDisabled` to notify_tx.
  2. Callback falls through the `current_pos.is_some()` branch and
     returns `CallbackResult::Drop` — *this very event*, plus any
     racing callback still in flight, get `set_type(Null)`'d and
     consumed.
  3. Outer task calls `handle_producer_event(..).unwrap_or_else(|e|
     log::error!(..))` — the `EventTapDisabled` error is just logged,
     the loop keeps running, `current_pos` stays `Some`, cursor
     stays hidden.

Net effect for the user: mouse motion keeps working (pass-through
when the tap is fully dead), but clicks and keypresses in the brief
disable window silently disappear, and the cursor is still hidden
where the captured session left it. Input looks broken until the
app is force-quit.

Fix:
- In the callback, when `TapDisabled*` fires, clear `current_pos`
  and `CGDisplay::show_cursor` synchronously, then return
  `CallbackResult::Keep` so this event (and any subsequent racing
  one) can't hit the drop branch.
- Mirror the cleanup in `handle_producer_event`'s
  `EventTapDisabled` arm so even if the outer task only logs the
  error, state is still released.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-04-29 22:59:43 +02:00

..

src

fix(input-capture): don't drop events after TCC Accessibility revocation

2026-04-29 22:59:43 +02:00

Cargo.toml

update ashpd

2026-04-08 13:11:18 +02:00