bug(web): message queuing (pending send) not working on mobile web

[hqhq1025]

Problem

On desktop web, when the agent is busy processing, users can type and submit a new message which gets queued as "pending" and is sent automatically once the agent finishes. However, on mobile web (iPhone PWA / mobile browser), this pending message queuing does not seem to work — the send button is either disabled or the message is not queued while the agent is running.

Steps to Reproduce

1. Open a session on mobile web (iPhone Safari / PWA)
2. Send a message and wait for the agent to start processing
3. While the agent is running, type a new message and try to send it

Expected: The message should be queued as "pending" and sent once the agent finishes (same as desktop web behavior).
Actual: The message cannot be sent / is not queued on mobile.

Comparison

• Desktop web: Pending message queuing works correctly
• Mobile web: Does not work

Environment

• iPhone, iOS, Safari / PWA
• Mobile web browsers in general

[github-actions]

Thanks, I checked the web send path in this repo.

I did not find a separate mobile-only queuing implementation. Desktop and mobile both go through the same web composer/runtime path, so this looks like a web-side bug rather than hub/CLI behavior.

What I verified:

• Sending while the agent is running is meant to stay available unless the composer is explicitly disabled; thread.isRunning and thread.isDisabled are tracked separately, and canSend is computed from text/attachments plus controlsDisabled in web/src/components/AssistantChat/HappyComposer.tsx:118, web/src/components/AssistantChat/HappyComposer.tsx:121, and web/src/components/AssistantChat/HappyComposer.tsx:135.
• Pressing Enter in the composer sends through the textarea onKeyDown path, which calls api.composer().send() at web/src/components/AssistantChat/HappyComposer.tsx:319.
• The form submit handler does not send; it only blocks incomplete attachments and clears a hint at web/src/components/AssistantChat/HappyComposer.tsx:435. The input also sets submitOnEnter={false} at web/src/components/AssistantChat/HappyComposer.tsx:784.
• The visible send control is a separate type="button" path in web/src/components/AssistantChat/ComposerButtons.tsx:246 and web/src/components/AssistantChat/ComposerButtons.tsx:287.
• The runtime/composer disabled state is driven by isSending, not by a mobile-specific branch: web/src/lib/assistant-runtime.ts:200, web/src/components/SessionChat.tsx:334, web/src/components/SessionChat.tsx:390, and web/src/hooks/mutations/useSendMessage.ts:106.
• I did not find mobile-specific send logic. The platform/PWA hooks are only used here for touch autofocus / iOS PWA layout handling: web/src/hooks/usePlatform.ts:70, web/src/hooks/usePWAInstall.ts:52, and web/src/components/AssistantChat/HappyComposer.tsx:172.

Based on that code path, one likely explanation is that the iPhone keyboard submit action is hitting form submit instead of the textarea onKeyDown send path. That part is an inference from the code above, not a confirmed repro.

Relevant code:

• web/src/components/AssistantChat/HappyComposer.tsx:118 - reads runtime thread.isRunning / thread.isDisabled
• web/src/components/AssistantChat/HappyComposer.tsx:319 - Enter key path calls api.composer().send()
• web/src/components/AssistantChat/HappyComposer.tsx:435 - form submit handler does not call send
• web/src/components/AssistantChat/HappyComposer.tsx:784 - composer input has submitOnEnter={false}
• web/src/components/AssistantChat/ComposerButtons.tsx:246 - send icon/button click path
• web/src/lib/assistant-runtime.ts:200 - runtime disabled state comes from isSending
• web/src/hooks/mutations/useSendMessage.ts:106 - send is blocked only while the mutation/resolve guard is pending

Need more info:

• When it fails on iPhone, are you using the on-screen send icon or the keyboard Send/Return action?
• Does it reproduce in both Safari tab and installed PWA, or only one?
• If you know it, which HAPI version or commit are you running?

---

HAPI Bot

[hqhq1025]

Clarification from reporter

The specific issue on iOS is:

• When the model is still processing/thinking, pressing Enter/Return on the iOS keyboard inserts a newline instead of sending (queuing) the message.
• On desktop web, pressing Enter while the agent is running correctly queues the message as "pending" and sends it once the agent finishes.

So the root cause is likely that on iOS, the Enter key action is treated as a newline rather than triggering the send path. This aligns with the bot's earlier analysis — submitOnEnter={false} is set on the composer input (HappyComposer.tsx:784), and the send is handled via onKeyDown (HappyComposer.tsx:319). On iOS, the keyboard's Return key may behave differently from desktop Enter in how it interacts with the onKeyDown handler.

To answer the bot's questions:

• Using the keyboard Return key, not the on-screen send icon
• Observed on iOS PWA

[hqhq1025]

Root cause clarification

The issue is not about the send path being broken — it's about the send button being replaced by the voice input button while the agent is running.

On mobile, when the agent is processing:

• The send button area shows the voice input button instead
• There is no way to tap "send" to queue a pending message
• On desktop, the Enter key can still send (queue) a message, but on mobile there's no keyboard Enter — the only send mechanism is the button, which is replaced by voice

This is likely in ComposerButtons.tsx where the button state toggles between send and voice based on whether the agent is running or idle.