fix(renderer): disable mouse tracking on destroy #515
Conversation
The destroy path was not explicitly disabling mouse tracking before tearing down native resources. While the zig-side performShutdownSequence() checks terminal.state.mouse, this relies on state synchronization that can fail silently in edge cases. Add explicit disableMouse() call in finalizeDestroy(), same as we do in suspend(), to send disable mouse escape sequence to the terminal before the renderer is freed. Fixes: anomalyco#509
|
Interesting. Just out of curiosity, do you know in what edge cases that would happen? I wonder because other states might be out of sync then as well. |
No specific repro beyond #509, but the class of edge cases is 'write didn't reach the TTY.' errors are swallowed, so if stdout is closed/piped or a write fails, the terminal can still be in mouse mode while state says false. This just sends a best‑effort disable before teardown. Other state flags could drift under the same failure mode, but i haven't looked into it extensively. |
|
Got it. But the native teardown is called always, so it could just unconditionally disable mouse? |
Let me go through the call paths again to make sure i understand it. |
2 participants
The destroy path was not explicitly disabling mouse tracking before tearing down native resources. While the zig-side
performShutdownSequence() checks terminal.state.mouse, this relies on state synchronization that can fail silently in edge cases.
Add explicit disableMouse() call in finalizeDestroy(), same as we do in suspend(), to send disable mouse escape sequence to the terminal before the renderer is freed.
Fixes: #509