Found while reviewing #441, which fixed the neighbouring half of this path. Pre-existing on master, not introduced there.
What happens
On a device whose keydowns report keyCode: 229 (Chrome on Android, and any soft keyboard that routes through composition), committing the last character of a prompt and pressing Enter in one InputConnection transaction makes xterm emit a stray DEL before the \r.
The mechanism is xterm's own keyCode-229 rescue. CompositionHelper.keydown() schedules _handleAnyTextareaChanges(), a zero-delay diff of textarea.value. Enter clears the textarea, so when that diff runs it sees the value shrink and emits the difference as a deletion. With local echo on (the default on every touch device, per MobileDetection.isTouchDevice()), that DEL reaches the composer before the \r does and eats a character.
Why it is worth a separate issue
#441 strictly improved this path rather than causing it: before that change the batched shape lost two characters here, after it one. So a report that still shows a missing character on an Android device after 1.30.0 is this, not a regression from #441, and I would rather that be written down somewhere than rediscovered.
Where to look
src/web/public/terminal-keycode229-recovery.js is the module that already owns the neighbouring case (an insertText xterm's _inputEvent guard refuses). It deliberately does not touch anything xterm emitted itself, which is why this is out of its scope as written.test/terminal-keycode229-recovery.browser.test.ts has the harness: it drives the real textarea and reports which bytes reach the send path and who produced them. The batched case added in ea5323d9 is the closest shape; a variant with keyCode: 229 and local echo enabled should show the stray DEL.
Not obvious, and worth deciding before writing code
Suppressing a DEL unconditionally would break real backspaces. The distinguishing evidence is that this one arrives from xterm's composition diff rather than from a key, in the same task as an Enter that has already cleared the textarea, so any fix needs to key off that rather than off the byte.
Not urgent: it costs one character in one input shape on one platform, and it has been there a while.
Found while reviewing #441, which fixed the neighbouring half of this path. Pre-existing on master, not introduced there.
What happens
On a device whose keydowns report
keyCode: 229(Chrome on Android, and any soft keyboard that routes through composition), committing the last character of a prompt and pressing Enter in one InputConnection transaction makes xterm emit a strayDELbefore the\r.The mechanism is xterm's own keyCode-229 rescue.
CompositionHelper.keydown()schedules_handleAnyTextareaChanges(), a zero-delay diff oftextarea.value. Enter clears the textarea, so when that diff runs it sees the value shrink and emits the difference as a deletion. With local echo on (the default on every touch device, perMobileDetection.isTouchDevice()), thatDELreaches the composer before the\rdoes and eats a character.Why it is worth a separate issue
#441 strictly improved this path rather than causing it: before that change the batched shape lost two characters here, after it one. So a report that still shows a missing character on an Android device after 1.30.0 is this, not a regression from #441, and I would rather that be written down somewhere than rediscovered.
Where to look
src/web/public/terminal-keycode229-recovery.jsis the module that already owns the neighbouring case (aninsertTextxterm's_inputEventguard refuses). It deliberately does not touch anything xterm emitted itself, which is why this is out of its scope as written.test/terminal-keycode229-recovery.browser.test.tshas the harness: it drives the real textarea and reports which bytes reach the send path and who produced them. The batched case added inea5323d9is the closest shape; a variant withkeyCode: 229and local echo enabled should show the strayDEL.Not obvious, and worth deciding before writing code
Suppressing a
DELunconditionally would break real backspaces. The distinguishing evidence is that this one arrives from xterm's composition diff rather than from a key, in the same task as an Enter that has already cleared the textarea, so any fix needs to key off that rather than off the byte.Not urgent: it costs one character in one input shape on one platform, and it has been there a while.