Sign up
View stargazersSign up

[Bug]: Shift+Enter does not insert a newline in iPad Safari web composer with Magic Keyboard#14869

openedOct 2, 2026byFFastdesigner

Before submitting

  • I searched existing reports. #5439 concerns the native iPad app and reversed Enter behavior; #2478 concerns Android/Chromium soft-keyboard newline handling. Both are closed.
  • I included the reporter's web-browser reproduction context.

Area

apps/web

Steps to reproduce

  1. Open the T3 Code web UI in Safari on an iPad through Tailscale.
  2. Connect a Magic Keyboard.
  3. Focus the message composer and type text.
  4. Press Shift+Enter to insert a new line.

Expected behavior

Shift+Enter inserts a line break in the composer without sending the message, as documented in docs/user/keybindings.md under iPad.

Actual behavior

The reporter cannot insert a new line using Shift+Enter. Whether the key combination sends the message or is ignored has not yet been captured. Keyboard-event traces and the installed Return-key setting are also not yet captured.

Environment

Safari on iPad, Magic Keyboard hardware keyboard, remote web UI over Tailscale, not the native iOS app.

Measured browser UA from a separate diagnostic in the same browser:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.6.1 Safari/605.1.15

navigator.platform: MacIntel, navigator.maxTouchPoints: 5.

Version or commit

Installed T3 version and exact iPadOS version not captured.

Impact

Hardware-keyboard users cannot compose multiline prompts through the documented shortcut.

Environment clarification from the reporter

T3 is installed on the iPad Home Screen using Safari Add to Home Screen and launched as a standalone Safari web app. The affected T3 session is not a normal Safari browser tab and not the native T3 iOS app. The separate hover diagnostic was opened in Safari; standalone display-mode media queries were not recorded for that diagnostic.

PProject51625d ago
Synced from GitHub

This was generated by AI during triage.

Additional reproduction reported on iPadOS 27.0.1 with a Logitech external keyboard and T3 Code 0.1.0.

With Send shortcut → Enter, pressing Shift+Enter submits the prompt instead of inserting a newline. The reporter reproduced this through T3 Connect and directly in Safari at app.t3.codes. Turning Rich text composer off did not resolve it.

The same keyboard's Shift+Enter inserts a newline in Apple Notes. The connected server's saved keybindings contain no plain Shift+Enter override.

Selecting ⌘ + Enter always allows plain Enter to insert newlines, but does not preserve the desired Enter-to-send / Shift+Enter-for-newline behavior.

Keyboard-event traces have not been captured, so the root cause remains unconfirmed. The exact Logitech model is unknown.

Prepared by Codex, model gpt-6.1-sol.

JJulius Marminge23d ago

Checked current main at b5a226e49c with vp run dev, an isolated copy of stopped thread data, and Linux Chromium 154. In a new-thread rich-text composer with Send shortcut → Enter, typing line one, pressing Shift+Enter, then typing line two kept both lines in the draft without submitting. Editor output: <p>line one</p><p>line two</p>.

This environment cannot verify iPad Safari's Home Screen standalone app with a Magic Keyboard; resizing Chromium would not reproduce that keyboard path. No matching open duplicate was found.

Please provide the affected T3 version/build and exact iPadOS version for the Magic Keyboard report, and confirm whether it still occurs on the latest build. A keyboard-event trace from the affected standalone app (keydown, keyup, and beforeinput, including key, code, shiftKey, isComposing, and inputType) would distinguish a lost Shift modifier from composer handling. Please record only those event fields, without prompt text or connection/pairing URLs. The follow-up already establishes that Shift+Enter submits with Send shortcut set to Enter and that disabling rich text does not help on its Logitech keyboard.

FFastdesigner22d ago
Synced from GitHub

Thanks for checking. I have now reproduced this again on the affected iPad and captured keyboard events directly in the Home Screen standalone web app.

Environment and behavior:

  • iPadOS 26.6.1.
  • Safari Add to Home Screen, launched as a standalone web app, using a Magic Keyboard, with reported hardware version 0007 and firmware version 0400.0140.0303 (exact keyboard model number not yet identified).
  • Connected T3 server reports 0.0.46-nightly.20261014.3093. This retest is on that installed nightly; I have not verified the latest build or current main. The build used for the original report was not recorded.
  • Send shortcut is set to Enter, confirmed in T3 settings.
  • Shift+Enter submits the message instead of inserting a newline. Plain Enter also submits.

I used temporary local client instrumentation: passive observation at window capture, without changing the composer or preventing/stopping events. Only Enter/Shift keyboard events and the requested beforeinput fields were retained; no printable-key events, prompt text, or connection/pairing URLs were recorded. Below are the relevant excerpts from the same recording, with unrelated typing events omitted.

Shift+Enter:

json
1[
2 {"type":"keydown","key":"Shift","code":"ShiftLeft","shiftKey":true,"isComposing":false,"inputType":null},
3 {"type":"keydown","key":"Enter","code":"Enter","shiftKey":true,"isComposing":false,"inputType":null},
4 {"type":"beforeinput","key":null,"code":null,"shiftKey":null,"isComposing":false,"inputType":"insertParagraph"},
5 {"type":"keyup","key":"Enter","code":"Enter","shiftKey":true,"isComposing":false,"inputType":null},
6 {"type":"keyup","key":"Shift","code":"ShiftLeft","shiftKey":false,"isComposing":false,"inputType":null}
7]

Plain Enter:

json
1[
2 {"type":"keydown","key":"Enter","code":"Enter","shiftKey":false,"isComposing":false,"inputType":null},
3 {"type":"beforeinput","key":null,"code":null,"shiftKey":null,"isComposing":false,"inputType":"insertParagraph"},
4 {"type":"keyup","key":"Enter","code":"Enter","shiftKey":false,"isComposing":false,"inputType":null}
5]

The Shift modifier is present on both captured Enter keyboard events for Shift+Enter. Both combinations produce beforeinput: insertParagraph. This rules out a missing Shift modifier at the window-capture observation point for this reproduction, but does not yet identify which downstream handler submits.

JJulius Marminge22d ago

Retested current main 3b95e7831b with vp run dev, an isolated snapshot of stopped threads, and Linux Chromium 154. Send shortcut was confirmed as Enter in Settings. In both rich-text and plain-text mode:

  • line one → Shift+Enter → line two kept both lines in the draft without submitting. DOM excerpt: <p dir="ltr">line one</p><p dir="ltr">line two</p>.
  • Starting empty → Shift+Enter → typing kept an empty paragraph followed by the typed paragraph, without submitting.

The new trace establishes that Shift reaches the window-capture listener on the affected standalone app. A downstream candidate remains: ProseMirror's iOS Enter handling can invoke the editor key handler with a synthetic Enter event without modifiers. This is a code finding, not a confirmed reproduction or root cause.

This Linux browser cannot exercise Safari's Home Screen standalone app with a physical Magic Keyboard. Please retest the affected iPad on the latest T3 build and report that build and whether Shift+Enter still submits with Send shortcut → Enter. The supplied retest was on 0.0.46-nightly.20261014.3093; current-main behavior on the affected device remains the missing check. No additional keyboard-model identification is needed for that check.

FFastdesigner22d ago
Synced from GitHub

@juliusmarminge I opened a focused fix in #23449, with failing-before/passing-after regression tests and labelled before/after evidence.

The distinction you made is preserved in the PR:

  • On the published, unpatched 0.1.2-nightly.20261022.3512 client, an automated replay that selects ProseMirror's iOS path before module initialization reaches the composer with a synthetic Enter lacking shiftKey. Starting empty, it consumes Shift+Enter without adding a paragraph. Send shortcut was confirmed as Enter in Settings. This is Chromium exercising that code path, not a physical iPad Safari reproduction.
  • On the actual affected iPad (iPadOS 26.6.1, Magic Keyboard, Home Screen standalone app), a client-only backport on the installed 0.0.46-nightly.20261014.3093 changed the observed behavior: Shift+Enter followed by Enter produced a two-line message, and the post-fix trace no longer has beforeinput: insertParagraph for Shift+Enter. Plain Enter still sends and retains that event.
  • The regression tests cover rich/plain mode, the original plain-Enter fallback, and active composition. vp run check:changed passes (16 tests across 3 files), as does the web production build.

The fix routes non-composing iOS Shift+Enter into the existing composer handler before ProseMirror substitutes the unmodified event. No local diagnostic UI or runtime backport tooling is included in the PR.

The unmodified latest-nightly hardware test on the physical iPad remains outstanding; I am not claiming that check is complete. The PR provides additional code-path evidence and the successful same-device backport trial for review.