What to build
On mobile, when a thread is busy/working, there is no keyboard affordance to queue a follow-up message. The queue capability exists — the primary send button relabels to "Queue" while the thread is busy, and a queueCount indicator shows how many messages are pending — but the only way to trigger it is by tapping the button.
Pressing Enter on the on-screen (soft) keyboard just inserts a newline. The native composer's onSubmit currently only fires on hardware Command-Return, so users on a phone with no hardware keyboard have no key-driven path to send/queue a message at all.
We should give the soft keyboard a way to queue/send — e.g. treat the keyboard's return/submit action as "queue when busy, send otherwise" (matching the button's existing behavior), while still allowing multi-line input (e.g. Shift/Enter or a dedicated newline affordance).
Relevant code:
apps/mobile/src/features/threads/ThreadComposer.tsx — sendLabel toggles between "Send"/"Queue" based on activeThreadBusy / queueCount; handleSend / onSendMessage.
apps/mobile/src/native/T3ComposerEditor.types.ts — onSubmit documented as fired only on hardware Command-Return.
Steps to reproduce
- On the mobile app, open a thread and start the agent working.
- Type a follow-up message in the composer.
- Press Enter on the on-screen keyboard.
Actual: A newline is inserted. The message can only be queued by tapping the "Queue" button.
Expected: There is a keyboard-driven way to queue the message (as on desktop), without losing the ability to enter newlines.
Acceptance criteria
What to build
On mobile, when a thread is busy/working, there is no keyboard affordance to queue a follow-up message. The queue capability exists — the primary send button relabels to "Queue" while the thread is busy, and a
queueCountindicator shows how many messages are pending — but the only way to trigger it is by tapping the button.Pressing Enter on the on-screen (soft) keyboard just inserts a newline. The native composer's
onSubmitcurrently only fires on hardware Command-Return, so users on a phone with no hardware keyboard have no key-driven path to send/queue a message at all.We should give the soft keyboard a way to queue/send — e.g. treat the keyboard's return/submit action as "queue when busy, send otherwise" (matching the button's existing behavior), while still allowing multi-line input (e.g. Shift/Enter or a dedicated newline affordance).
Relevant code:
apps/mobile/src/features/threads/ThreadComposer.tsx—sendLabeltoggles between "Send"/"Queue" based onactiveThreadBusy/queueCount;handleSend/onSendMessage.apps/mobile/src/native/T3ComposerEditor.types.ts—onSubmitdocumented as fired only on hardware Command-Return.Steps to reproduce
Actual: A newline is inserted. The message can only be queued by tapping the "Queue" button.
Expected: There is a keyboard-driven way to queue the message (as on desktop), without losing the ability to enter newlines.
Acceptance criteria
queueCountindicator updates correctly for keyboard-queued messages.