Reported as "no way to send a left click". `xinput --query-state` on the
display showed `Shift_L` down on the XTEST device with nothing holding it, so
every click reached the game as shift-click, which Minesweeper reads as a right
click. The board flagged instead of opening and nothing about the panel looked
wrong.
Mine, from the keyboard work two commits ago, and two separate mistakes.
── modifiers should never have been sent ──
Press shift, release it while the canvas no longer has focus, and the keyup
never arrives — the key is then down on the server forever. They are also
POINTLESS: `ev.key` is the character the layout already produced, so a shifted
key arrives as `A` and x11vnc presses shift itself to type it. Sending our own
on top was redundant on the good path and load-bearing on the bad one.
`keysymFor` now returns null for them, which also hands them back to the
browser — shift-tab should still move focus out of a game of Minesweeper.
── and nothing released what was held ──
Any key can strand the same way, so the panel now tracks what it has pressed
and releases it on blur and on unmount. Cheap, and the failure it prevents is
invisible from the panel: the server has no way to know a key was released
somewhere it could not see.
The live display is unstuck too — `xdotool keyup` on the modifiers, since the
fix stops it happening again but does not undo the one already stranded.
The general lesson, which is the same one the difficulty command taught: input
synthesised into another program's session is state you now own. Press without
a guaranteed release is a leak, and it does not look like one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: de3ed4e6-f88a-429c-94e6-a760336ba83b
pastilhasandClaude Opus 5
02a816c8dc