feat(control): opt-in input tracing to locate mis-placed clicks - #50
Merged
Conversation
The remaining click failure cannot be diagnosed by reading the code. Whether the pointer has actually arrived by the time a button event is delivered depends on when the OS applies a synthetic move, which is only observable at runtime. Adds PAIRUX_DEBUG_INPUT=1 tracing that records, per button event, the normalized coordinates, the absolute pixels we asked for, the position read back from the OS immediately before the press, and the drift between them. Non-zero drift means the settle delay is too short and the click is landing somewhere other than where the guest aimed. Also logs nut-js's screen geometry at init, which is the other half of a mis-placed click: if that disagrees with the display's real geometry — Retina reporting physical pixels where setPosition wants logical points — every coordinate is scaled wrong and no delay fixes it. On the injector side it records the two-cursor bookkeeping around each click, so a restore firing between a down and its up (which would yank the pointer mid-click, and is invisible in the backend's own trace) shows up. Off unless explicitly set to "1": it costs a window-server round trip per button event and prints the coordinates of everything the remote peer clicks.
ThreatCrush Security Scan160 finding(s) HIGH/CRITICAL: 5 | MEDIUM: 49 | LOW: 106
…and 110 more. Full results in the Security tab. Snippets are redacted; ThreatCrush never prints matched credential material. |
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
1 participant
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.
Whether the pointer has actually arrived by the time a button event is
delivered depends on when the OS applies a synthetic move. That is not
knowable from the code, so this adds the measurement.
PAIRUX_DEBUG_INPUT=1records, per button event: the normalized coordinates,the absolute pixels requested, the position read back from the OS immediately
before the press, and the drift between them. Non-zero drift means the settle
delay added in #49 is too short and the click is landing somewhere other than
where the guest aimed.
Also logs nut-js's screen geometry at init — the other half of a mis-placed
click. If that disagrees with the display's real geometry (Retina reporting
physical pixels where setPosition wants logical points), every coordinate is
scaled wrong and no delay fixes it.
On the injector side it records the two-cursor bookkeeping around each click,
so a restore firing between a down and its up — which would yank the pointer
mid-click, and is invisible in the backend's own trace — shows up.
Off unless explicitly set to "1": it costs a window-server round trip per
button event and prints the coordinates of everything the remote peer clicks.
Shipping it disabled-by-default so a host hitting this can produce a log
without needing a custom build.