fix(video-recorder): only enable Send after a recording exists#39980
fix(video-recorder): only enable Send after a recording exists#39980ManjeetMMIV wants to merge 1 commit into
Conversation
|
|
Looks like this PR is not ready to merge, because of the following issues:
Please fix the issues and try again If you have any trouble, please check the PR guidelines |
WalkthroughThe changes modify Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested labels
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ 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. Comment |
There was a problem hiding this comment.
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 callsstopRecording(), and thenstopVideoRecording()(line 96) calls it again. The second call will returnfalse, 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
📒 Files selected for processing (3)
apps/meteor/app/ui/client/lib/recorderjs/videoRecorder.spec.tsapps/meteor/app/ui/client/lib/recorderjs/videoRecorder.tsapps/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.tsapps/meteor/client/views/composer/VideoMessageRecorder/VideoMessageRecorder.tsxapps/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.tsextension 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.tsapps/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.tsapps/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
falsereturn path. Consider adding a complementary test for thetruecase (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
recordingAvailablestate correctly decouples "Send" enablement from camera status, addressing the bug where Send was enabled without actual recording data.
58-59: Good use of thestopRecording()return value.This correctly enables "Send" only when
stopRecording()confirms a recording was actually stopped.
| public stopRecording() { | ||
| if (!this.started || !this.recording || !this.mediaRecorder) { | ||
| return; | ||
| return false; | ||
| } | ||
|
|
||
| this.mediaRecorder.stop(); | ||
| this.recording.set(false); | ||
| delete this.mediaRecorder; | ||
| return true; | ||
| } |
There was a problem hiding this comment.
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.
| 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.
Proposed changes
Sendwhen recording data is actually available, not merely when the camera preview is activerecordingAvailablestate and reset behavior during recording/cancel/send flowsstopRecording()reports whether a recording actually existedIssue(s)
Steps to test or reproduce
Sendbutton remains disabledSendbecomes enabled only after a real recording is availableFurther comments
Summary by CodeRabbit
Bug Fixes
Tests