Summary
Triggering the terminal bell from a shell session — e.g. printf '\a', an echo -e '\x07', or any program that emits BEL — produces no client-side feedback. No sound, no flash, no indicator pill. The byte is silently dropped.
Repro
In an active TermiWeb instance, run any of:
printf '\a'echo -e '\x07'- A program that emits BEL on completion (e.g. some long-running CLIs,
tput bel).
Expected: some indication that the terminal bell fired (sound, visual flash, status pill, or all three).
Actual: nothing happens client-side.
Root cause
This is a missing feature, not a regression:
- The xterm.js terminal is constructed at
src/client/main.ts:116 with no bellStyle option. xterm.js defaults bellStyle to "none", so BEL bytes are silently consumed on the canvas.
- No
terminal.onBell(...) listener is wired anywhere in src/client, so we can't surface a custom visual or audio cue either.
- The server pty path (
src/server/terminal/terminal-manager.ts) just relays bytes, which is the right behavior — the gap is purely client-side wiring.
Grepping audio, bell, beep, AudioContext, bellStyle, onBell across src/ returns zero matches outside CSS class names, confirming there is no audio surface at all.
Suggested fix direction
Smallest viable: set bellStyle: "sound" (or "visual" if we want to avoid surprise audio) when constructing the xterm Terminal, and consider wiring terminal.onBell to flash the active instance pill or play a short tone via AudioContext so behavior is consistent across browsers (Chromium-based browsers, including Brave/Edge/Android Chrome, do not implement xterm's built-in "sound" reliably without a user gesture / autoplay caveat).
If we want richer behavior:
- Visual flash on the active instance card and/or terminal frame border.
- Optional audio cue gated behind a user preference (and a one-time user-gesture unlock for
AudioContext).
- Track a per-instance "needs attention" indicator in the sidebar so background instances surface bells.
A spec entry would be appropriate before implementation — bell behavior is product behavior, not just a code fix.
Notes
- Found during 0.1.1 dogfooding.
- Mobile autoplay restrictions mean any audio path needs a one-time user-gesture unlock; that has to be part of the design.
Summary
Triggering the terminal bell from a shell session — e.g.
printf '\a', anecho -e '\x07', or any program that emits BEL — produces no client-side feedback. No sound, no flash, no indicator pill. The byte is silently dropped.Repro
In an active TermiWeb instance, run any of:
printf '\a'echo -e '\x07'tput bel).Expected: some indication that the terminal bell fired (sound, visual flash, status pill, or all three).
Actual: nothing happens client-side.
Root cause
This is a missing feature, not a regression:
src/client/main.ts:116with nobellStyleoption. xterm.js defaultsbellStyleto"none", so BEL bytes are silently consumed on the canvas.terminal.onBell(...)listener is wired anywhere insrc/client, so we can't surface a custom visual or audio cue either.src/server/terminal/terminal-manager.ts) just relays bytes, which is the right behavior — the gap is purely client-side wiring.Grepping
audio,bell,beep,AudioContext,bellStyle,onBellacrosssrc/returns zero matches outside CSS class names, confirming there is no audio surface at all.Suggested fix direction
Smallest viable: set
bellStyle: "sound"(or"visual"if we want to avoid surprise audio) when constructing the xterm Terminal, and consider wiringterminal.onBellto flash the active instance pill or play a short tone viaAudioContextso behavior is consistent across browsers (Chromium-based browsers, including Brave/Edge/Android Chrome, do not implement xterm's built-in"sound"reliably without a user gesture / autoplay caveat).If we want richer behavior:
AudioContext).A spec entry would be appropriate before implementation — bell behavior is product behavior, not just a code fix.
Notes