draft: diagnosis for #9418 (typing order on slow systems)

[lonexreb]

Summary

This is a draft diagnosis PR, not a fix. Issue #9418 reports printable characters appearing out of order while typing on a resource-constrained Linux Mint 21.3 XFCE machine. I traced the full input pipeline and could not find an actual race or reorder; opening a draft so a maintainer can weigh in before any speculative code change lands.

Closes: nothing yet — needs more info from reporter to make this actionable.

What this PR changes

A single comment in crates/warpui/src/windowing/winit/event_loop/mod.rs in the ConvertedEvent::KeyDownWithTypedCharacters arm, documenting the ordering invariant of the printable-character hot path. Zero behavior change.

Investigation trace

End-to-end pipeline for a printable keypress on Linux:

1. Event::WindowEvent { WindowEvent::KeyboardInput } arrives on the winit event loop (single-threaded). event_loop/mod.rs:1270
2. convert_keyboard_input_event (sync, pure). event_loop/key_events.rs:60
3. handle_converted_warpui_event dispatches KeyDown, then TypedCharacters if unhandled. event_loop/mod.rs:1081-1100
4. dispatch_event is fully synchronous; any side effects emitted via ctx.emit go onto the pending_effects: VecDeque<Effect> and are drained pop_front in FIFO order. core/app.rs:3136
5. TerminalView::typed_characters_on_terminal -> system_insert (editor) or write_user_bytes_to_pty -> ctx.emit(Event::WriteBytesToPty). terminal/view.rs:7979-8009
6. Subscription -> PtyController::write_bytes -> send_message_to_event_loop(Message::Input). writeable_pty/pty_controller.rs:636-735
7. mio channel -> EventLoop::drain_recv_channel -> state.write_list.push_back(input) (a VecDeque<Cow<[u8]>>). local_tty/event_loop.rs:164-176
8. Write loop consumes write_list front-to-back to the PTY fd.

Every hop is FIFO; the entire flow runs on the UI thread; there is no background-thread hop for printable characters; pending_flushes/flushing_effects guards in core/app.rs prevent re-entrant flush reorder. No coalescing, no batching, no debounce in this path.

Why I am not shipping a code fix

The reporter's symptom — letters arriving in a different order than typed on a Linux Mint machine with 8GB RAM — is the kind of bug where a speculative fix is more likely to regress good behavior than to fix the real cause. Probable real causes that the current report cannot disambiguate:

• Display latency, not insertion order. Under heavy load, render frames could lag per-character, making characters appear briefly out of order even though they were processed in order. The reporter has not provided a screen recording confirming insertion order vs render order.
• Xorg/winit-level reordering on this specific hardware/driver combo. A 2012 MacBook Pro running Linux Mint XFCE has well-known graphics-stack quirks. winit's X11 backend, the xkb composition state, or even a low-level input method (ibus/fcitx) could be involved. The reporter did not say whether an IME is active.
• IME Ime::Preedit interleaving with KeyboardInput. On Linux with IME enabled, winit emits both keyboard events and Ime::Preedit/Ime::Commit. These are processed in arrival order, but if the user is typing fast and the IME is committing pre-edits asynchronously at the OS level, characters can land non-monotonically. This is OS/IME behavior, not Warp.
• Stale Warp version. The reporter never gave a version or channel, and oz-for-oss already requested both.

Required follow-up before a fix can be designed

1. Screen recording showing the symptom and roughly what was typed vs what appeared.
2. Exact Warp version and channel.
3. Whether an IME (ibus, fcitx, scim) is active on the reporter's system.
4. Warp logs from a session in which this reproduces.

oz-for-oss already requested 1 and 2 on the issue; this PR documents the diagnostic ground truth so a maintainer doesn't have to redo the trace.

Test plan

• N/A — comment-only change, no behavior modified.
• When the reporter supplies a recording + version + IME info, revisit and design a targeted fix (most likely an IME interleave guard or render-side per-frame coalescing, scoped to Linux).

🤖 Generated with Claude Code