Web client silently discards slash command text after the first line break before it reaches the command handler

[Freedom101]

Description

When a slash command is typed in the message composer and the text contains a line break (Shift+Enter), the client drops everything after the first line break before the command is executed. Neither core slash commands nor Apps-Engine apps ever receive the remaining lines, and the user gets no feedback that part of their input was thrown away.

The cause is the parse regex in apps/meteor/client/lib/chats/flows/processSlashCommand.ts:

const parse = (msg: string): ... => {
	const match = msg.match(/^\/([^\s]+)(.*)/);
	...
};

(.*) is evaluated without the s (dotall) flag, so it stops matching at the first \n. The params string passed to commands.run therefore contains only the remainder of the first line.

The server side already handles multi-line parameters correctly: apps/meteor/lib/utils/parseParameters.ts splits on newlines for unquoted text and preserves newlines inside quoted strings. Invoking the same command through POST /api/v1/commands.run with multi-line params works as expected, which confirms the truncation is purely client-side.

Steps to reproduce

1. In the web client composer, type a core slash command such as /msg, press Shift+Enter, and continue the text on a second line, for example:

   /msg @alice
   don't forget the standup
   

2. Send the message.

Expected behavior

The full parameter text, including the line break, is passed to the command handler, matching what parseParameters on the server already supports. Alternatively, if multi-line slash commands are unsupported by design, the client should say so instead of silently discarding input.

Actual behavior

Only the text before the first line break is passed (@alice in the example), so the direct message body is lost with no warning. The same applies to any Apps-Engine app command that takes free text. Sending the identical params string through POST /api/v1/commands.run delivers the full multi-line text correctly.

Suggested fix

Add the dotall flag to the parse regex so params capture spans line breaks:

const match = msg.match(/^\/([^\s]+)(.*)/s);

Server-side handling needs no change; parseParameters already deals with newlines in both quoted and unquoted positions.

Server Setup Information

• Version of Rocket.Chat Server: 8.6.0 (reproduced; the regex is unchanged on current develop)
• Client: web client (the truncation is in the shared client flow, so desktop is affected equally)
• Apps-Engine version: 1.64.0

Additional context

Found while developing an Apps-Engine app whose slash command takes a free-text message. Users who put the message text on a new line after the command keyword lose the entire message body. An app can detect the resulting dangling parameters and hint at the limitation, but it cannot recover the discarded text, so this is not fixable at the app level.

[coderabbitai]

🔗 Related PRs

#40259 - chore: reorganize backend folder structure — Phase 1 (slash commands) [merged]
#40788 - fix: workspace crashing when invalid regular expression is used on message search query [merged]
#41007 - fix: Composer AutoGrow causing the message list to shift [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[dsaicharan072-cmyk]

Hello @Freedom101
Thanks for the detailed writeup and repro steps — this is a clear, well-isolated bug.

I'd like to pick this up. The fix looks straightforward (adding the s flag to the parse regex in processSlashCommand.ts as suggested), but I'll also verify:

• Quoted multi-line params still parse correctly through parseParameters.ts after the client-side change.
• Existing core commands (/msg, etc.) and Apps-Engine commands aren't affected by any edge cases in the regex change.
• Add a regression test covering multi-line slash command input in the composer flow.

Will submit a PR shortly and link it here.

[dsaicharan072-cmyk]

Thanks @hiSandog, this is helpful — will incorporate all three points:

• Adding regression tests for LF, CRLF, and an intentional blank line within the params, asserting the exact remaining text is received in each case.
• Testing pasted multi-line text and typed Shift+Enter line breaks as separate cases, and checking the composer code for any input-path-specific normalization before it reaches processSlashCommand.
• Checking whether any core or Apps-Engine commands are intended to be single-line-only. If so, I'll make sure rejection happens explicitly in the parser rather than relying on client-side truncation.

Will update this thread once the PR is up.