Skip to content

fix(video-recorder): only enable Send after a recording exists#39980

Open
ManjeetMMIV wants to merge 1 commit into
RocketChat:developfrom
ManjeetMMIV:fix/livechat-video-recorder-send-button
Open

fix(video-recorder): only enable Send after a recording exists#39980
ManjeetMMIV wants to merge 1 commit into
RocketChat:developfrom
ManjeetMMIV:fix/livechat-video-recorder-send-button

Conversation

@ManjeetMMIV
Copy link
Copy Markdown

@ManjeetMMIV ManjeetMMIV commented Mar 30, 2026

Proposed changes

  • Fix video recorder send button logic in VideoMessageRecorder.tsx
  • Only enable Send when recording data is actually available, not merely when the camera preview is active
  • Added recordingAvailable state and reset behavior during recording/cancel/send flows
  • Updated recorder helper videoRecorder.ts so stopRecording() reports whether a recording actually existed
  • Added regression test coverage in videoRecorder.spec.ts

Issue(s)

  • Fixes bug where “Send” was enabled without recording

Steps to test or reproduce

  1. Open the message composer video recorder
  2. Start recording
  3. Stop without creating a valid recording
  4. Confirm the Send button remains disabled
  5. Confirm Send becomes enabled only after a real recording is available

Further comments

  • This is a small focused bug fix
  • Only the recorder UI state and helper behavior were changed
  • No additional feature or documentation changes were required

Summary by CodeRabbit

  • Bug Fixes

    • Improved Send button logic in video message recorder to only enable when an actual recording exists, preventing incomplete submissions.
  • Tests

    • Added unit test coverage for edge cases in video recording functionality.

@ManjeetMMIV ManjeetMMIV requested a review from a team as a code owner March 30, 2026 16:44
@changeset-bot
Copy link
Copy Markdown

changeset-bot Bot commented Mar 30, 2026

⚠️ No Changeset found

Latest commit: 956971a

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@dionisio-bot
Copy link
Copy Markdown
Contributor

dionisio-bot Bot commented Mar 30, 2026

Looks like this PR is not ready to merge, because of the following issues:

  • This PR is missing the 'stat: QA assured' label
  • This PR is missing the required milestone or project

Please fix the issues and try again

If you have any trouble, please check the PR guidelines

Copy link
Copy Markdown
Contributor

@cubic-dev-ai cubic-dev-ai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues found across 3 files

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented Mar 30, 2026

Walkthrough

The changes modify VideoRecorder.stopRecording() to return a boolean indicating operation success, add test coverage for the case when no recording is active, and update the UI component to use this return value to control send button availability.

Changes

Cohort / File(s) Summary
Test Coverage
apps/meteor/app/ui/client/lib/recorderjs/videoRecorder.spec.ts
Added unit test asserting stopRecording() returns false when invoked without active recording state.
Recorder Implementation
apps/meteor/app/ui/client/lib/recorderjs/videoRecorder.ts
Modified stopRecording() method to return boolean; returns false when recorder is not in valid state, and true upon successful stop.
UI Component
apps/meteor/client/views/composer/VideoMessageRecorder/VideoMessageRecorder.tsx
Added recordingAvailable state flag to gate send button; updated disable logic to check both !recordingAvailable and recordingState === 'recording'. Sets recordingAvailable based on stopRecording() return value and during state transitions.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Suggested labels

type: bug

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately describes the main change: a fix to enable the Send button only when a valid recording exists, which is the core issue addressed across all three modified files.
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.


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

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

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
apps/meteor/client/views/composer/VideoMessageRecorder/VideoMessageRecorder.tsx (1)

94-97: Minor redundancy: stopRecording() is called twice.

VideoRecorder.stop(cb) (line 94) internally calls stopRecording(), and then stopVideoRecording() (line 96) calls it again. The second call will return false, and line 97 overrides the state anyway, so the final behavior is correct. This is acceptable but worth noting for future refactoring.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In
`@apps/meteor/client/views/composer/VideoMessageRecorder/VideoMessageRecorder.tsx`
around lines 94 - 97, The code calls stopRecording twice: VideoRecorder.stop(cb)
already invokes stopRecording, then stopVideoRecording(rid, tmid) calls it
again; remove the redundancy by either (A) removing the explicit
stopVideoRecording(rid, tmid) call here and keep state updates (setTime,
setRecordingAvailable), or (B) change stopVideoRecording to accept a no-op/guard
when the recorder is already stopped so it doesn't call stopRecording again;
update references to VideoRecorder.stop, stopVideoRecording, and
setRecordingAvailable accordingly.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/meteor/app/ui/client/lib/recorderjs/videoRecorder.ts`:
- Around line 143-152: The stopRecording method currently checks the ReactiveVar
object instead of its value, so change the conditional to use
this.recording.get() (e.g., if (!this.started || !this.recording.get() ||
!this.mediaRecorder) return false;) in the stopRecording function to properly
inspect the recording state; keep the existing this.recording.set(false) and
mediaRecorder.stop()/delete this.mediaRecorder behavior unchanged.

---

Nitpick comments:
In
`@apps/meteor/client/views/composer/VideoMessageRecorder/VideoMessageRecorder.tsx`:
- Around line 94-97: The code calls stopRecording twice: VideoRecorder.stop(cb)
already invokes stopRecording, then stopVideoRecording(rid, tmid) calls it
again; remove the redundancy by either (A) removing the explicit
stopVideoRecording(rid, tmid) call here and keep state updates (setTime,
setRecordingAvailable), or (B) change stopVideoRecording to accept a no-op/guard
when the recorder is already stopped so it doesn't call stopRecording again;
update references to VideoRecorder.stop, stopVideoRecording, and
setRecordingAvailable accordingly.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 47681320-1e00-4e18-a5f3-c5d40ced4de3

📥 Commits

Reviewing files that changed from the base of the PR and between 4235cd9 and 956971a.

📒 Files selected for processing (3)
  • apps/meteor/app/ui/client/lib/recorderjs/videoRecorder.spec.ts
  • apps/meteor/app/ui/client/lib/recorderjs/videoRecorder.ts
  • apps/meteor/client/views/composer/VideoMessageRecorder/VideoMessageRecorder.tsx
📜 Review details
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{ts,tsx,js}

📄 CodeRabbit inference engine (.cursor/rules/playwright.mdc)

**/*.{ts,tsx,js}: Write concise, technical TypeScript/JavaScript with accurate typing in Playwright tests
Avoid code comments in the implementation

Files:

  • apps/meteor/app/ui/client/lib/recorderjs/videoRecorder.spec.ts
  • apps/meteor/client/views/composer/VideoMessageRecorder/VideoMessageRecorder.tsx
  • apps/meteor/app/ui/client/lib/recorderjs/videoRecorder.ts
**/*.spec.ts

📄 CodeRabbit inference engine (.cursor/rules/playwright.mdc)

**/*.spec.ts: Use descriptive test names that clearly communicate expected behavior in Playwright tests
Use .spec.ts extension for test files (e.g., login.spec.ts)

Files:

  • apps/meteor/app/ui/client/lib/recorderjs/videoRecorder.spec.ts
🧠 Learnings (8)
📚 Learning: 2025-11-24T17:08:17.065Z
Learnt from: CR
Repo: RocketChat/Rocket.Chat PR: 0
File: .cursor/rules/playwright.mdc:0-0
Timestamp: 2025-11-24T17:08:17.065Z
Learning: Applies to apps/meteor/tests/e2e/**/*.spec.ts : Ensure tests run reliably in parallel without shared state conflicts

Applied to files:

  • apps/meteor/app/ui/client/lib/recorderjs/videoRecorder.spec.ts
📚 Learning: 2025-11-24T17:08:17.065Z
Learnt from: CR
Repo: RocketChat/Rocket.Chat PR: 0
File: .cursor/rules/playwright.mdc:0-0
Timestamp: 2025-11-24T17:08:17.065Z
Learning: Applies to apps/meteor/tests/e2e/**/*.spec.ts : Use `expect` matchers for assertions (`toEqual`, `toContain`, `toBeTruthy`, `toHaveLength`, etc.) instead of `assert` statements in Playwright tests

Applied to files:

  • apps/meteor/app/ui/client/lib/recorderjs/videoRecorder.spec.ts
📚 Learning: 2026-02-24T19:22:48.358Z
Learnt from: juliajforesti
Repo: RocketChat/Rocket.Chat PR: 38493
File: apps/meteor/tests/e2e/omnichannel/omnichannel-send-pdf-transcript.spec.ts:66-67
Timestamp: 2026-02-24T19:22:48.358Z
Learning: In Playwright end-to-end tests (e.g., under apps/meteor/tests/e2e/...), prefer locating elements by translated text (getByText) and ARIA roles (getByRole) over data-qa attributes. If translation values change, update the corresponding test locators accordingly. Never use data-qa locators. This guideline applies to all Playwright e2e test specs in the repository and helps keep tests robust to UI text changes and accessible semantics.

Applied to files:

  • apps/meteor/app/ui/client/lib/recorderjs/videoRecorder.spec.ts
📚 Learning: 2026-02-26T19:25:44.063Z
Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 38778
File: packages/ui-voip/src/providers/useMediaSession.ts:192-192
Timestamp: 2026-02-26T19:25:44.063Z
Learning: In the Rocket.Chat repository, do not reference Biome lint rules in code review feedback. Biome is not used even if biome.json exists; only reference Biome rules if there is explicit, project-wide usage documented. For TypeScript files, review lint implications without Biome guidance unless the project enables Biome rules.

Applied to files:

  • apps/meteor/app/ui/client/lib/recorderjs/videoRecorder.spec.ts
  • apps/meteor/app/ui/client/lib/recorderjs/videoRecorder.ts
📚 Learning: 2026-02-26T19:25:44.063Z
Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 38778
File: packages/ui-voip/src/providers/useMediaSession.ts:192-192
Timestamp: 2026-02-26T19:25:44.063Z
Learning: In this repository (RocketChat/Rocket.Chat), Biome lint rules are not used even if a biome.json exists. When reviewing TypeScript files (e.g., packages/ui-voip/src/providers/useMediaSession.ts), ensure lint suggestions do not reference Biome-specific rules. Rely on general ESLint/TypeScript lint rules and project conventions instead.

Applied to files:

  • apps/meteor/app/ui/client/lib/recorderjs/videoRecorder.spec.ts
  • apps/meteor/app/ui/client/lib/recorderjs/videoRecorder.ts
📚 Learning: 2026-03-06T18:10:15.268Z
Learnt from: tassoevan
Repo: RocketChat/Rocket.Chat PR: 39397
File: packages/gazzodown/src/code/CodeBlock.spec.tsx:47-68
Timestamp: 2026-03-06T18:10:15.268Z
Learning: In tests (especially those using testing-library/dom/jsdom) for Rocket.Chat components, the HTML <code> element has an implicit ARIA role of 'code'. Therefore, screen.getByRole('code') or screen.findByRole('code') will locate <code> elements even without a role attribute. Do not flag findByRole('code') as invalid in reviews; prefer using the implicit role instead of adding role="code" unless necessary for accessibility.

Applied to files:

  • apps/meteor/app/ui/client/lib/recorderjs/videoRecorder.spec.ts
📚 Learning: 2026-02-26T19:22:36.646Z
Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 38778
File: packages/ui-voip/src/views/CallHistoryContextualbar/CallHistoryActions.tsx:40-40
Timestamp: 2026-02-26T19:22:36.646Z
Learning: In packages/ui-voip/src/views/CallHistoryContextualbar/CallHistoryActions.tsx, when the media session state is 'unavailable', the voiceCall action is not included in the actions object passed to CallHistoryActions, so it won't appear in the menu at all. The action filtering happens upstream before getItems is called, preventing any tooltip confusion for the unavailable state.

Applied to files:

  • apps/meteor/client/views/composer/VideoMessageRecorder/VideoMessageRecorder.tsx
📚 Learning: 2026-03-27T14:52:56.865Z
Learnt from: dougfabris
Repo: RocketChat/Rocket.Chat PR: 39892
File: apps/meteor/client/views/room/contextualBar/Threads/Thread.tsx:150-155
Timestamp: 2026-03-27T14:52:56.865Z
Learning: In Rocket.Chat, there are two different `ModalBackdrop` components with different prop APIs. During review, confirm the import source: (1) `rocket.chat/fuselage` `ModalBackdrop` uses `ModalBackdropProps` based on `BoxProps` (so it supports `onClick` and other Box/DOM props) and does not have an `onDismiss` prop; (2) `rocket.chat/ui-client` `ModalBackdrop` uses a narrower props interface like `{ children?: ReactNode; onDismiss?: () => void }` and handles Escape keypress and outside mouse-up, and it does not forward arbitrary DOM props such as `onClick`. Flag mismatched props (e.g., `onDismiss` passed to the fuselage component or `onClick` passed to the ui-client component) and ensure the usage matches the correct component being imported.

Applied to files:

  • apps/meteor/client/views/composer/VideoMessageRecorder/VideoMessageRecorder.tsx
🔇 Additional comments (3)
apps/meteor/app/ui/client/lib/recorderjs/videoRecorder.spec.ts (1)

177-179: Good regression test for the new return value.

The test validates the false return path. Consider adding a complementary test for the true case (when stopping an active recording) to ensure complete coverage of the new behavior.

apps/meteor/client/views/composer/VideoMessageRecorder/VideoMessageRecorder.tsx (2)

47-49: Clean implementation of the recording availability check.

The new recordingAvailable state correctly decouples "Send" enablement from camera status, addressing the bug where Send was enabled without actual recording data.


58-59: Good use of the stopRecording() return value.

This correctly enables "Send" only when stopRecording() confirms a recording was actually stopped.

Comment on lines 143 to 152
public stopRecording() {
if (!this.started || !this.recording || !this.mediaRecorder) {
return;
return false;
}

this.mediaRecorder.stop();
this.recording.set(false);
delete this.mediaRecorder;
return true;
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Bug: !this.recording checks the ReactiveVar object, not its value.

this.recording is a ReactiveVar<boolean> (line 8), so the object itself is always truthy. The check !this.recording is always false. Should use .get() to check the actual recording state, consistent with usage elsewhere in this file (e.g., line 74).

The bug is currently masked because !this.mediaRecorder provides similar protection, but this should be fixed for correctness.

Proposed fix
 public stopRecording() {
-    if (!this.started || !this.recording || !this.mediaRecorder) {
+    if (!this.started || !this.recording.get() || !this.mediaRecorder) {
         return false;
     }

     this.mediaRecorder.stop();
     this.recording.set(false);
     delete this.mediaRecorder;
     return true;
 }
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
public stopRecording() {
if (!this.started || !this.recording || !this.mediaRecorder) {
return;
return false;
}
this.mediaRecorder.stop();
this.recording.set(false);
delete this.mediaRecorder;
return true;
}
public stopRecording() {
if (!this.started || !this.recording.get() || !this.mediaRecorder) {
return false;
}
this.mediaRecorder.stop();
this.recording.set(false);
delete this.mediaRecorder;
return true;
}
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@apps/meteor/app/ui/client/lib/recorderjs/videoRecorder.ts` around lines 143 -
152, The stopRecording method currently checks the ReactiveVar object instead of
its value, so change the conditional to use this.recording.get() (e.g., if
(!this.started || !this.recording.get() || !this.mediaRecorder) return false;)
in the stopRecording function to properly inspect the recording state; keep the
existing this.recording.set(false) and mediaRecorder.stop()/delete
this.mediaRecorder behavior unchanged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants