Enable Enter key to send debate messages

[vinayak302004]

Closes #280

What changed

• Added Enter key handling to the debate message input
• Pressing Enter now sends the message
• Shift + Enter remains supported

Why

Improves usability and matches standard chat behavior.

Summary by CodeRabbit

• New Features
  • Added keyboard shortcut support for the debate room. Users can now send messages by pressing Enter, while Shift+Enter allows composing multiline messages.

[coderabbitai]

📝 Walkthrough

Walkthrough

The change adds an onKeyDown event handler to the user input field in the DebateRoom component. When Enter is pressed alone, it triggers sendMessage() and prevents the default newline. Shift+Enter continues to create newlines as expected.

Changes

Cohort / File(s)	Summary
Input Handler Enhancement frontend/src/Pages/DebateRoom.tsx	Adds onKeyDown event handler to user input field to send messages when Enter is pressed (without Shift), while preserving Shift+Enter for newlines.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Poem

🐰 A rabbit hops with glee so bright,
The Enter key now works just right!
No more must clickers click the send,
A simple press—your message's end! ✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'Enable Enter key to send debate messages' directly and clearly describes the main change: adding Enter key functionality to send messages in the debate room.
Linked Issues check	✅ Passed	The PR implements all requirements from issue #280: Enter sends messages, Shift+Enter allows newlines, and uses onKeyDown handler for input as specified.
Out of Scope Changes check	✅ Passed	All changes in DebateRoom.tsx are directly related to the Enter key functionality objective; no out-of-scope modifications are present.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@frontend/src/Pages/DebateRoom.tsx`:
- Around line 863-868: The Enter handler on the Input should not send while
speech recognition is active and the Shift+Enter check is misleading for a
single-line <Input>; update the onKeyDown handler used around the Input
component so it first checks isRecognizing and returns early (do not call
sendMessage when isRecognizing is true), and remove or ignore the !e.shiftKey
clause since the shadcn/ui Input is single-line (if multiline later, switch to a
textarea and reintroduce the Shift+Enter logic); reference the existing
onKeyDown arrow handler, the isRecognizing flag, and the sendMessage() function
when making this change.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

The Enter-to-send logic is correct; two minor observations.

1. Shift+Enter guard is a no-op here: The <Input> component (shadcn/ui) renders a single-line <input>, which cannot produce newlines regardless. The !e.shiftKey check is harmless but the PR description's claim about "Shift+Enter inserts a newline" doesn't apply to this element. If multiline input is actually desired in the future, this would need to be a <textarea> instead.

2. Enter fires during speech recognition: The input is readOnly (not disabled) while isRecognizing is true (line 869), so the onKeyDown handler still fires. Pressing Enter mid-dictation would call sendMessage() and send whatever partial transcript has accumulated in finalInput. Consider guarding against this:

Proposed fix

 onKeyDown={(e) => {
-  if (e.key === "Enter" && !e.shiftKey) {
+  if (e.key === "Enter" && !e.shiftKey && !isRecognizing) {
     e.preventDefault();
     sendMessage();
   }
 }}

🤖 Prompt for AI Agents

In `@frontend/src/Pages/DebateRoom.tsx` around lines 863 - 868, The Enter handler
on the Input should not send while speech recognition is active and the
Shift+Enter check is misleading for a single-line <Input>; update the onKeyDown
handler used around the Input component so it first checks isRecognizing and
returns early (do not call sendMessage when isRecognizing is true), and remove
or ignore the !e.shiftKey clause since the shadcn/ui Input is single-line (if
multiline later, switch to a textarea and reintroduce the Shift+Enter logic);
reference the existing onKeyDown arrow handler, the isRecognizing flag, and the
sendMessage() function when making this change.