Repository navigation
Conversation
Touch keyboards have no Shift key, so plain Enter now inserts the same line break as Shift+Enter on desktop, and the send button submits the prompt. Mod+Enter still submits for external keyboards, and desktop behavior is unchanged. Fixes anomalyco#55549
|
The following comment was made by an LLM, it may be inaccurate: |
There was a problem hiding this comment.
This looks good to me. I reproduced the bug in Playwright on an emulated touch phone (390px, hasTouch/isMobile). On the base, Enter sent "first line" and left only "second line" in the composer. With this change no prompt is sent, the composer holds first line\nsecond line, and Send submits it. Your new e2e case fails on the base and passes here. The rest of the spec (desktop and non-touch 390px, where Enter still sends) passes on both. Enter in the suggestion popover behaves the same as on the base, because controller.onKeyDown runs before the new branch. bun run typecheck is clean.
The public API is unchanged.
One small point: on a touch device with a hardware keyboard (for example an iPad keyboard without a trackpad, which still matches (hover: none)), the only way to send from the keyboard is now Mod+Enter. That key is the alternate delivery (it switches queue/steer while a turn is running), not a plain submit. It's probably fine for this fix, but it's worth knowing that it isn't quite "Mod+Enter still submits".
Issue for this PR
Closes #55549
Type of change
What does this PR do?
On touch devices, the composer submits the prompt on every plain Enter press. Mobile soft keyboards have no Shift key, so there is no way to compose a multi-line prompt at all.
This adds a touch branch to
onKeyDowninpackages/app/src/composer/editor/editor.tsx: when the device has no hover pointer (@media (hover: none)), plain Enter inserts a line break instead of submitting, and the send button remains the way to submit.Mod+Enterstill submits for external keyboards, and desktop behavior (Enter submits, Shift+Enter inserts a newline) is unchanged.The break is inserted with
document.execCommand("insertLineBreak"), which produces the same DOM as desktop Shift+Enter — the path the composer's parser already handles — so the newline survives submission as a single\n.preventDefault()is only called when the insertion succeeds; if the command returns false, the browser's default insertion still runs, so Enter never submits either way. I used a(hover: none)media query rather than a viewport width check because landscape phones (e.g. 844px) and tablets would be missed by a< 768pxrule.How did you verify your code works?
e2e/regression/mobile-composer-submit-focus.spec.ts(touch context, 390px): type "first line", press Enter, type "second line", tap Send, then assert the POSTed prompt text is exactly"first line\nsecond line"and the composer is emptied. The case fails ondev(Enter submits immediately) and passes with the change.--repeat-each=10 --workers=4 --retries=0for the new case: 10/10 passed. The full spec file: 5/5 passed.bun run typecheck(packages/app) andbun run typecheck:e2eare clean for the changed files.Screenshots / recordings
Before — Enter submits immediately and the composer is emptied:
After — Enter keeps both lines in the composer, and the send button submits them as one prompt:
Checklist
Added by the opencode bot (AI-generated).
Related: #43088, #55341