ekklesiaandClaude Opus 5
0e91b4cbd3
The Close button followed focus, and moving the pointer down to the dock moves focus off the popup. So the button disappeared somewhere on the journey to it, and a secondary Chrome window could not be closed with a mouse at all. Found on the endpoint; my fault. The target is remembered instead. Once a secondary window has been focused the dock keeps offering to close it, and losing focus — to the dock, the main browser, a print dialog, any layer-shell surface — changes nothing. It moves on only when that window closes or another secondary takes over, and it falls back to another open secondary rather than to nothing, so cancelling a print dialog leaves the render window still closeable. It is chosen from the secondary list, which never contains the first window, so it can never name the main browser. Restoring the floating role to a window that already existed no longer moves or focuses it. Moving it would undo wherever the teacher dragged it; focusing it would raise the render window over the print dialog sitting above it, which is one way the print flow was getting disturbed. Verified by driving a real pointer through the exact path that was broken: pointer over the popup, click to focus, then travel down to the dock in steps, screenshotting throughout. The button is still there on arrival, at 992,1041. Then the print flow: main browser, render window and a separate Print dialog, pointer to the dock, button still there, and killing the dialog leaves the render window as the new target with the main browser untouched. The button's own action could not be actuated in that harness, because synthetic pointer input does not reach Wayland clients under headless sway — the Browser button does not respond to it either. The action was run directly instead, closing exactly the remembered container and leaving main Chrome alive. Co-Authored-By: Claude Opus 5 <[email protected]>
2 lines
7 B
Plaintext
2 lines
7 B
Plaintext
0.1.43
|