Uh oh!
There was an error while loading. Please reload this page.
fix: Don't trigger keybindings view on input burst - #7980
Conversation
All contributors have signed the CLA ✍️ ✅ |
pedrovhb
commented
Dec 13, 2025
I have read the CLA Document and I hereby sign the CLA |
etraut-openai
commented
Dec 15, 2025
@codex review |
Codex Review: Didn't find any major issues. Hooray! ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
etraut-openai
commented
Dec 15, 2025
Thanks for the contribution. Looks good. For future PRs, please file a bug report. We prefer that all bug fixes have an associated bug report. It helps us track and prioritize, especially in cases where the we decide to reject the PR for some reason. |
Uh oh!
There was an error while loading. Please reload this page.
Human TL;DR - in some situations, pasting/rapidly inputting text will currently cause
?characters to be stripped from the input message content, and display the key bindings helper. For instance, writing "Where is X defined? Can we do Y?" results in "Where is X defined Can we do Y" being added to the message draft area. This is mildly annoying.The fix was a simple one line addition. Added a test, ran linters, and all looks good to me. I didn't create an issue to link to in this PR - I had submitted this bug as a report a while ago but can't seem to find it now. Let me know if it's an absolute must for the PR to be accepted.
I have read the CLA Document and I hereby sign the CLA
Below is Codex's summary.
?characters toggling shortcuts / being droppedSymptom
On Termux (and potentially other terminal environments), composing text in the native input field and sending it to the TTY can cause:
?was pressed on an empty prompt), and?characters in the text to be missing from the composer input,even when
?is not the first character.This typically happens when the composer was previously empty and the terminal delivers the text as a rapid sequence of key events rather than a single bracketed paste event.
Root cause
The TUI has two relevant behaviors:
Shortcut toggle on
?when emptyChatComposer::handle_shortcut_overlay_keytreats a plain?press as a toggle between the shortcut summary and the full shortcut overlay, but only when the composer is empty.?is not inserted into the text input).“Paste burst” buffering for fast key streams
In Termux’s “send composed text all at once” mode, the input often arrives as a very fast stream of
KeyCode::Char(...)events. While that stream is being buffered as a burst, the visible textarea can still be empty. If a?arrives during this window, it matches “empty composer” and is interpreted as “toggle shortcuts” instead of “insert literal?”, so the?is dropped.Fix
Make the
?toggle conditional on not being in any paste-burst transient state.Implementation:
ChatComposer::handle_shortcut_overlay_keynow checks!self.is_in_paste_burst()in addition toself.is_empty()before toggling.?is treated as normal text input rather than a UI toggle.Test coverage
Added a test that simulates a Termux-like fast stream:
h i ? t h e r eas immediate successiveKeyEvent::Charevents (no delays).?("hi?there"), andShortcutOverlay.Notes
This fix intentionally keeps the existing UX:
?still toggles shortcuts when the composer is genuinely empty and the user is not in the middle of entering text.?typed while composing content (including IME/native-input fast streams) remains literal.