fix: preserve chat input when queued messages are sent (#7861) #7870

hannesrudolph · 2025-09-10T23:02:31Z

Related GitHub Issue

Closes: #7861

Roo Code Task Context (Optional)

No Roo Code task context for this PR

Description

This PR fixes a bug where the chat input was being cleared when queued messages were sent, even if the user had typed new text in the meantime.

Key Changes:

Added a fromQueue parameter to handleSendMessage to distinguish between user-initiated sends and queue-processed messages
Modified the invoke handler to detect when a message is being sent from the queue
Only clear the input when fromQueue is false, preserving user input for queued messages

Implementation Details:

When the backend processes a queued message, it sends an "invoke sendMessage" to the frontend
The fix checks if the invoked message matches any message in the queue to determine if it's from the queue
This ensures the input is preserved when processing queued messages but still cleared for normal message sends

Test Procedure

Automated Tests:

Added comprehensive unit tests in ChatView.queuedMessages.spec.tsx
Tests verify that input is preserved when processing queued messages
Tests verify that input is cleared for normal message sends
All existing tests continue to pass

Manual Testing:

Open Roo Code extension
Start a task that causes sending to be disabled (e.g., during approval waiting)
Queue a message while sending is disabled
Type new text in the chatbox (do not send)
Wait for the queued message to be processed
Verify that your typed text remains in the chatbox

Pre-Submission Checklist

Issue Linked: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
Scope: My changes are focused on the linked issue (one major feature/fix per PR).
Self-Review: I have performed a thorough self-review of my code.
Testing: New and/or updated tests have been added to cover my changes (if applicable).
Documentation Impact: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
Contribution Guidelines: I have read and agree to the Contributor Guidelines.

Screenshots / Videos

No UI changes in this PR - the fix is behavioral (preserving input text)

Documentation Updates

No documentation updates are required.

Additional Notes

This bug affected users who had messages queued (e.g., while approval is pending) and then typed new text before the queue processed. The fix ensures a better user experience by preserving their typed content.

Get in Touch

Available via GitHub for questions

Important

Fixes chat input clearing issue by adding fromQueue parameter to handleSendMessage in ChatView.tsx, preserving input for queued messages.

Behavior:
- Adds fromQueue parameter to handleSendMessage in ChatView.tsx to differentiate between user-initiated and queue-processed messages.
- Modifies message handling to preserve input when fromQueue is true.
Testing:
- Adds ChatView.queuedMessages.spec.tsx to test input preservation for queued messages and clearing for regular messages.
- Tests include scenarios with and without images.

^{This description was created by}^{for 9784d07. You can customize this summary. It will automatically update as commits are pushed.}

When a queued message is sent, the chat input was being cleared even if the user had typed new text. This fix: - Adds a fromQueue parameter to handleSendMessage to track when messages are sent from the queue - Checks if invoke sendMessage corresponds to a queued message to determine fromQueue status - Only clears the input when fromQueue is false, preserving user input for queued messages - Adds comprehensive tests to verify the behavior Fixes #7861

Copilot

Pull Request Overview

This PR fixes a bug where the chat input was being cleared when queued messages were sent, even if the user had typed new text in the meantime. The fix ensures that user input is preserved when messages are processed from the queue but still cleared for normal message sends.

Key Changes:

Added a fromQueue parameter to handleSendMessage to distinguish between user-initiated sends and queue-processed messages
Enhanced the message processing logic to detect when messages originate from the queue
Only clear the input when messages are not from the queue, preserving user input for queued messages

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
`webview-ui/src/components/chat/ChatView.tsx`	Modified `handleSendMessage` to accept `fromQueue` parameter and preserve input for queued messages
`webview-ui/src/components/chat/__tests__/ChatView.queuedMessages.spec.tsx`	Added comprehensive unit tests covering queued message scenarios and input preservation

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

Copilot · 2025-09-10T23:03:02Z

webview-ui/src/components/chat/ChatView.tsx

+							const isFromQueue = messageQueue.some(
+								(queuedMsg) =>
+									queuedMsg.text === message.text &&
+									JSON.stringify(queuedMsg.images || []) === JSON.stringify(message.images || []),
+							)


Using JSON.stringify for array comparison is inefficient and could be problematic for large images. Consider using a more efficient array comparison method or a deep equality check.

Copilot · 2025-09-10T23:03:02Z

webview-ui/src/components/chat/ChatView.tsx


 			if (text || images.length > 0) {
-				if (sendingDisabled) {
+				if (sendingDisabled && !fromQueue) {


This condition prevents queued messages from being processed when sending is disabled. Queued messages should be able to be sent even when sendingDisabled is true, since they were already queued when sending was enabled.

roomote

Thank you for your contribution! I've reviewed the changes and found that this is a well-implemented fix that addresses the issue described in #7861. The approach is sound and the tests are comprehensive. I have a few suggestions for improvement.

roomote · 2025-09-10T23:07:05Z

webview-ui/src/components/chat/ChatView.tsx

+							const isFromQueue = messageQueue.some(
+								(queuedMsg) =>
+									queuedMsg.text === message.text &&
+									JSON.stringify(queuedMsg.images || []) === JSON.stringify(message.images || []),


I agree with the previous comment - using JSON.stringify for array comparison is inefficient, especially for large images. Consider using a more efficient array comparison method:

Suggested change

JSON.stringify(queuedMsg.images || []) === JSON.stringify(message.images || []),

const isFromQueue = messageQueue.some(

(queuedMsg) =>

queuedMsg.text === message.text &&

queuedMsg.images?.length === message.images?.length &&

queuedMsg.images?.every((img, idx) => img === message.images?.[idx])

)

Or better yet, use a deep equality utility like lodash's isEqual.

roomote · 2025-09-10T23:07:06Z

webview-ui/src/components/chat/ChatView.tsx


 			if (text || images.length > 0) {
-				if (sendingDisabled) {
+				if (sendingDisabled && !fromQueue) {


Is this the intended behavior? The condition if (sendingDisabled && !fromQueue) means that when fromQueue is true, the message will proceed to be sent even if sendingDisabled is true. This allows queued messages to bypass the sending disabled state. Could you confirm this is the desired behavior for your use case?

roomote · 2025-09-10T23:07:06Z

webview-ui/src/components/chat/__tests__/ChatView.queuedMessages.spec.tsx

+			expect(textarea.value).toBe("User typing while image message queued")
+		})
+	})
+})


Great test coverage! Consider adding a few more edge case tests:

Multiple queued messages being processed sequentially

Queue processing when sending becomes re-enabled

Race conditions between user input and queue processing

These would help ensure the feature remains robust as the codebase evolves.

Copilot AI review requested due to automatic review settings September 10, 2025 23:02

hannesrudolph requested review from cte, jr and mrubens as code owners September 10, 2025 23:02

github-project-automation bot added this to Roo Code Roadmap and Roo Code Roadmap Sep 10, 2025

github-project-automation bot moved this to Triage in Roo Code Roadmap Sep 10, 2025

github-project-automation bot moved this to New in Roo Code Roadmap Sep 10, 2025

dosubot bot added size:L This PR changes 100-499 lines, ignoring generated files. bug Something isn't working labels Sep 10, 2025

Copilot AI reviewed Sep 10, 2025

View reviewed changes

roomote bot reviewed Sep 10, 2025

View reviewed changes

hannesrudolph added the Issue/PR - Triage New issue. Needs quick review to confirm validity and assign labels. label Sep 10, 2025

hannesrudolph closed this Sep 11, 2025

github-project-automation bot moved this from New to Done in Roo Code Roadmap Sep 11, 2025

github-project-automation bot moved this from Triage to Done in Roo Code Roadmap Sep 11, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix: preserve chat input when queued messages are sent (#7861) #7870

fix: preserve chat input when queued messages are sent (#7861) #7870

Uh oh!

hannesrudolph commented Sep 10, 2025 •

edited by ellipsis-dev bot

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Sep 10, 2025

Uh oh!

Copilot AI Sep 10, 2025

Uh oh!

roomote bot left a comment

Uh oh!

roomote bot Sep 10, 2025

Uh oh!

roomote bot Sep 10, 2025

Uh oh!

roomote bot Sep 10, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

fix: preserve chat input when queued messages are sent (#7861) #7870

fix: preserve chat input when queued messages are sent (#7861) #7870

Uh oh!

Conversation

hannesrudolph commented Sep 10, 2025 • edited by ellipsis-dev bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Related GitHub Issue

Roo Code Task Context (Optional)

Description

Test Procedure

Pre-Submission Checklist

Screenshots / Videos

Documentation Updates

Additional Notes

Get in Touch

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Copilot AI Sep 10, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Sep 10, 2025

Choose a reason for hiding this comment

Uh oh!

roomote bot left a comment

Choose a reason for hiding this comment

Uh oh!

roomote bot Sep 10, 2025

Choose a reason for hiding this comment

Uh oh!

roomote bot Sep 10, 2025

Choose a reason for hiding this comment

Uh oh!

roomote bot Sep 10, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

hannesrudolph commented Sep 10, 2025 •

edited by ellipsis-dev bot

Loading