98 lines
4.2 KiB
Markdown
98 lines
4.2 KiB
Markdown
# Deferred: Ghostty mobile long-press copy
|
||
|
||
## Summary
|
||
|
||
Mobile long-press copy for highlighted terminal text should be implemented in Ghostty ownership layer, not in `webterm/static/js/terminal.ts`.
|
||
|
||
## Note
|
||
|
||
- Selection, copy, context menu, and touch-selection semantics are owned by `ghostty-web`, mainly `lib/selection-manager.ts`.
|
||
- Wrapper-level gesture handling in `webterm/static/js/terminal.ts` is not correct long-term fix for “long press highlighted text to copy”.
|
||
- Future work should patch Ghostty selection manager directly so long-press copy uses Ghostty’s real selection state and copy path.
|
||
|
||
# Bug: Render loop dies silently on uncaught exception
|
||
|
||
## Summary
|
||
|
||
The `requestAnimationFrame` render loop in `Terminal.startRenderLoop()` has no error handling. If `renderer.render()`, `wasmTerm.getCursor()`, or any other expression in the loop body throws an exception, the `requestAnimationFrame(loop)` call at the end of the function is never reached. The loop stops permanently and the canvas is never repainted, even though the terminal remains fully functional underneath.
|
||
|
||
## Symptoms
|
||
|
||
- The terminal canvas freezes — no visual updates.
|
||
- Keyboard input continues to flow normally to the backend (the WebSocket and `write()` path are unaffected).
|
||
- A full page reload recovers immediately because a fresh `Terminal` instance starts a new render loop.
|
||
- The stall is intermittent and not correlated with any specific user interaction (no resize, no focus change required). It can happen at any time during normal terminal output.
|
||
|
||
## Root cause
|
||
|
||
`startRenderLoop()` currently looks like this:
|
||
|
||
```typescript
|
||
private startRenderLoop(): void {
|
||
const loop = () => {
|
||
if (!this.isDisposed && this.isOpen) {
|
||
this.renderer!.render(
|
||
this.snapshotBuffer,
|
||
false,
|
||
this.viewportY,
|
||
this,
|
||
this.scrollbarOpacity
|
||
);
|
||
|
||
const cursor = this.wasmTerm!.getCursor();
|
||
if (cursor.y !== this.lastCursorY) {
|
||
this.lastCursorY = cursor.y;
|
||
this.cursorMoveEmitter.fire();
|
||
}
|
||
|
||
this.animationFrameId = requestAnimationFrame(loop);
|
||
}
|
||
};
|
||
loop();
|
||
}
|
||
```
|
||
|
||
The entire body — WASM calls, renderer canvas operations, cursor queries, event emitter dispatch — runs unprotected. Any exception (a WASM trap surfacing as a JS error, a canvas context issue, an unexpected `null` from `getLine()` / `getCursor()`, a listener throwing in `cursorMoveEmitter.fire()`) kills the loop with no log output and no recovery.
|
||
|
||
Because `write()` pushes data directly into the WASM buffer synchronously and does not depend on the render loop, all subsequent terminal state updates succeed silently — the user just never sees them.
|
||
|
||
## Proposed fix
|
||
|
||
Wrap the render loop body in `try/catch` so that `requestAnimationFrame(loop)` is always reached:
|
||
|
||
```typescript
|
||
private startRenderLoop(): void {
|
||
const loop = () => {
|
||
if (!this.isDisposed && this.isOpen) {
|
||
try {
|
||
this.renderer!.render(
|
||
this.snapshotBuffer,
|
||
false,
|
||
this.viewportY,
|
||
this,
|
||
this.scrollbarOpacity
|
||
);
|
||
|
||
const cursor = this.wasmTerm!.getCursor();
|
||
if (cursor.y !== this.lastCursorY) {
|
||
this.lastCursorY = cursor.y;
|
||
this.cursorMoveEmitter.fire();
|
||
}
|
||
} catch (e) {
|
||
console.error('[ghostty-web] render loop error (recovering):', e);
|
||
}
|
||
|
||
this.animationFrameId = requestAnimationFrame(loop);
|
||
}
|
||
};
|
||
loop();
|
||
}
|
||
```
|
||
|
||
This keeps the loop alive across transient failures and logs the error so the underlying cause can be diagnosed. The next frame will call `render()` again normally — most renderer errors are frame-specific (e.g., a particular combination of dirty rows and viewport state) and resolve on the next pass.
|
||
|
||
## Impact
|
||
|
||
- **Without the fix:** a single exception permanently freezes the terminal display until the user reloads the page.
|
||
- **With the fix:** the frame is skipped, an error is logged to the console, and the next frame renders normally. There is no performance cost in the non-error path (try/catch in modern JS engines is zero-overhead when no exception is thrown).
|