Feat(chat): add queued message UI with auto-send

[unclebay143]

Summary

Adds a queued message UX to the chat input. While the AI is responding, new user messages are queued and automatically sent in order once the model becomes ready.

Why

Previously, users had to wait until the AI finished responding before sending another message. This new UX improves flow and usability by letting users queue multiple thoughts without interruption.

Screenshots

1. Default (AI responding, queue collapsed)

2. Expanded (view all queued messages)

3. Hover state (remove a queued message)

Key Features

• Collapsible queue panel above the input that visually merges with the input card.
• Auto-flush: sends one queued message at a time when status === 'ready'.
• Per-item removal from the queue.

Notes

• Stop button remains visible only when streaming and input is empty (intentional UX).
• Queue UI extracted to components/elements/queue.tsx; state/side-effects remain in components/multimodal-input.tsx.

[vercel]

@unclebay143 is attempting to deploy a commit to the Vercel Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

Suggested change

	{status === 'submitted' && !input.trim() ? (
	{status === 'submitted' ? (

The StopButton now disappears when users start typing during AI responses, removing their ability to stop the AI mid-response.

View Details

Analysis

StopButton Visibility Bug During Message Queuing

Bug Description

The StopButton component disappears when users start typing during AI responses, preventing them from stopping the AI mid-response. This occurs due to an overly restrictive visibility condition that conflicts with the queue feature.

Technical Analysis

Root Cause

The issue is in components/multimodal-input.tsx at line 414, where the StopButton visibility condition is:

{status === 'submitted' && !input.trim() ? (
  <StopButton stop={stop} setMessages={setMessages} />
) : (
  <PromptInputSubmit ... />
)}

How the Bug Manifests

1. Queue Feature Context: The application implements a message queue feature that allows users to type new messages while the AI is responding (when status === 'submitted')
2. Conflicting Logic: When a user starts typing during an AI response:
   • status remains 'submitted' (AI still processing)
   • input.trim() becomes truthy (user has typed content)
   • The condition status === 'submitted' && !input.trim() evaluates to true && false = false
   • StopButton disappears and is replaced with SubmitButton

User Impact

• Loss of Control: Users lose the ability to stop AI responses once they begin composing their next message
• Poor UX: The queue feature encourages typing during AI responses but then penalizes users by removing stop functionality
• Productivity Impact: Users cannot quickly halt irrelevant or incorrect AI responses when they've started typing, forcing them to wait for completion

Evidence and Validation

User Expectations Research

Research into AI chat interface patterns reveals that users expect stop buttons to be available throughout AI response generation. The OpenAI Developer Community discussion highlights that stop functionality is considered critical for:

• Immediately halting incorrect responses
• Quickly refining prompts mid-generation
• Preventing lengthy irrelevant explanations

Code Analysis

The queue implementation shows clear intent to support concurrent user input:

// In submitForm callback
if (status === 'ready') {
  sendMessage({ role: 'user', parts });
} else {
  setMessageQueue((q) => [...q, { parts }]); // Queue when AI is busy
}

This design explicitly allows and encourages user input during AI processing, making the input-dependent StopButton condition counterproductive.

Solution

Fix Implementation

Changed the StopButton visibility condition from:

status === 'submitted' && !input.trim()

To:

status === 'submitted'

Why This Fix Works

1. Preserves Queue Functionality: Users can still type and queue messages during AI responses
2. Maintains Stop Access: StopButton remains available regardless of input state during AI processing
3. Consistent UX: Aligns with user expectations that stop functionality should always be accessible during AI generation
4. Simple and Robust: Removes the fragile dependency on input state that created the conflict

Testing

The fix was validated through behavioral testing that confirmed:

• StopButton now remains visible when status === 'submitted' regardless of input content
• Users can both queue new messages AND stop current AI responses
• No regression in existing functionality

Impact Assessment

Severity: Medium-High
User Experience: Significantly improved
Risk: Low (simple, well-contained change)

This fix resolves a genuine usability issue where a valuable feature (message queuing) inadvertently disabled another critical feature (stop functionality), creating a poor user experience that contradicts standard AI chat interface patterns.

[unclebay143]

The Stop button remains available until the user starts typing. Once they begin typing, the assumption is that they’ve shifted focus to their next message. At that point, they can still stop the AI before typing, or after sending the new message to the queue. This is an intentional implementation.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
ai-chatbot	Ready	Preview	Comment	Sep 10, 2025 3:39pm

[unclebay143]

rearrangement due to merge conflict with upstream.