Repository navigation
[Bug]: Android: terminal typing echo is abnormally slow (per-keystroke delay) #12756
Description
Activity
Triage
Confirmed performance bug in the Android terminal input path. This is not a one-off device glitch.
What the code does today
Characters are not painted when the key is pressed. They only appear after a full remote round-trip:
- The native Android surface (
apps/mobile/modules/t3-terminal/android/.../T3TerminalView.kt) uses a hidden 1×1EditText/ IME watcher and immediately emitsonInput, then clears the field. The Ghostty canvas is not updated here. - JS (
ThreadTerminalRouteScreen→terminalEnvironment.write) sends a unary write RPC per keystroke. - The character shows only when PTY output comes back on the attach stream and is rematerialized as a full
initialBufferstring (use-terminal-session.ts: “until the native streaming API is released”). - Native then prefix-diffs that string, feeds Ghostty, and snapshots the canvas.
So echo latency is network RTT + JS rematerialization + native feed/repaint. Desktop/web use the same remote-echo model but usually have much lower RTT, so they feel instant. Android also pays IME cost (field is cleared every key;
TYPE_TEXT_VARIATION_VISIBLE_PASSWORDto suppress suggestions).iOS uses the same remote-buffer architecture; this was only reported on Android.
Related
- Sibling IME issue on the same hidden
EditText: [Bug]: Android: terminal input triggers password-manager autofill (Bitwarden) and shows incognito keyboard icon #12755 - Open work that helps the write/render path but does not add local echo:
- perf(client-runtime): batch terminal input writes #9456 — batch / fire-and-forget terminal input writes
- fix(mobile): stream terminal output incrementally #11235 — stream mobile output incrementally (drop full
initialBufferrematerialization) - perf(terminal): stream output and history #9027 — broader terminal output/history streaming
Suggested direction
- Treat this as a real Android terminal latency bug (high UX impact, not crash/data-loss).
- Best fix: optimistic/local echo in the native surface for printable keys so the canvas updates before the PTY reply. iOS likely wants the same.
- Landing perf(client-runtime): batch terminal input writes #9456 / fix(mobile): stream terminal output incrementally #11235 / perf(terminal): stream output and history #9027 should still happen — they cut per-keystroke RPC and rematerialization — but they will not make typing feel native by themselves.
Optional repro notes if easy: does the same environment’s web/desktop terminal feel instant? Does iOS show the same delay?
- The native Android surface (
I don't own an iOS device unfortunately 😕 but I can confirm that at least on fedora and the web it is instant
Before submitting
Area
apps/mobile
Steps to reproduce
Expected behavior
Keystrokes should echo on screen immediately — imperceptibly, comparable to a native or desktop terminal. Typing in the terminal should feel instant.
Actual behavior
There is a consistently noticeable delay between tapping a key and the character appearing in the terminal. It happens on every keystroke, so typing feels abnormally slow overall.
Worth checking as likely causes: whether every keystroke waits for a full network round-trip before rendering (no local echo / no optimistic echo), and per-keystroke re-render overhead in the terminal view itself.
Impact
Major degradation or frequent failure
Environment
🤖 GLM 5.3 Flash on behalf of iliasgws