♿️(frontend) set explicit document title on recording download page

[Ovgodd]

Purpose

The browser tab showed only the generic app title (e.g. “LaSuite Meet” / “Visio”) on the recording download page, so users could not quickly tell which tab or context they were in.

Proposal

• Explicit tab title when the recording is ready (success.title)
• Title aligned with the “not ready” state (unsaved.title) when the recording status is not saved / not downloadable ye

[lebaudantoine]

LGTM; I've not tested it locally. Please double check it, to make sure you don't introduce any regression.

[lebaudantoine]

@coderabbitai full review

[coderabbitai]

✅ Actions performed

Full review triggered.

[coderabbitai]

Walkthrough

This pull request adds dynamic document title handling to the RecordingDownload page. The implementation imports the useTitle hook and useMemo, derives a page title based on recording status conditions (isSaved, error state, and expiration status), and applies it to update the browser title. The CHANGELOG.md is updated to document this new feature and correct minor whitespace formatting.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly describes the main change: adding explicit document title handling to the recording download page frontend component.
Description check	✅ Passed	The description is directly related to the changeset, explaining the purpose (generic tab title problem) and the implemented proposal (dynamic titles per state).
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

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/frontend/src/features/recording/routes/RecordingDownload.tsx`:
- Around line 63-65: The tab title precedence is inverted: the title checks
evaluate data?.is_expired before isSaved but the UI renders the unsaved state
first; update the title logic in RecordingDownload so it checks the unsaved
condition before the expired condition (i.e., evaluate data && !isSaved ->
`${APP_TITLE} - ${t('unsaved.title')}` prior to checking data?.is_expired),
keeping the existing checks for data && isSaved and the same t(...) keys so the
tab title matches the rendered page state.
- Around line 56-59: The downloadable-status check is duplicated: you already
compute isSaved (using RecordingStatus.Saved,
RecordingStatus.NotificationSucceed, RecordingStatus.FailedToStop) but later
re-check the same set in the render guard; update the render condition inside
the RecordingDownload component to reuse the isSaved boolean instead of
repeating the status array so the single source of truth (isSaved) is used for
both logic and rendering.

🪄 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: Repository UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 8e588060-babe-45ca-865a-2a954036330f

📥 Commits

Reviewing files that changed from the base of the PR and between 170763a and 3d46f85.

📒 Files selected for processing (2)

• CHANGELOG.md
• src/frontend/src/features/recording/routes/RecordingDownload.tsx

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Reuse isSaved in the render guard to avoid status drift.

isSaved centralizes the downloadable statuses, but the same status set is duplicated again later in the component. Reusing isSaved in the render condition prevents future divergence.

Suggested refactor

-  if (
-    data.status !== RecordingStatus.Saved &&
-    data.status !== RecordingStatus.NotificationSucceed &&
-    data.status !== RecordingStatus.FailedToStop
-  ) {
+  if (!isSaved) {
     return <ErrorScreen title={t('unsaved.title')} body={t('unsaved.body')} />
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/frontend/src/features/recording/routes/RecordingDownload.tsx` around
lines 56 - 59, The downloadable-status check is duplicated: you already compute
isSaved (using RecordingStatus.Saved, RecordingStatus.NotificationSucceed,
RecordingStatus.FailedToStop) but later re-check the same set in the render
guard; update the render condition inside the RecordingDownload component to
reuse the isSaved boolean instead of repeating the status array so the single
source of truth (isSaved) is used for both logic and rendering.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud