fix: pad-wide view settings apply to the creator's own view (#7900)

[JohnMcLear]

Found while fixing #7900 (split out from #7901, which covers the page-flip bug).

Problem

After the pad creator has at some point toggled their personal "Read content from right to left", setting pad-wide RTL (and enforcing it) does nothing on the creator's own screen — the content stays LTR.

Root cause

The pad creator is never "enforced upon themselves" (isPadSettingsEnforcedForMe() is false whenever canEditPadSettings() is true), so getEffectivePadOptions() always merges their personal view overrides (cookies) on top of the pad-wide options. A stale rtlIsTrue=false cookie therefore silently masks the pad-wide value the creator just set.

Fix

When the creator changes a pad-wide view option, sync their personal pref to the chosen value (changePadViewOption → setMyViewOption), so their own view adopts the pad-wide setting immediately.

This deliberately does not change the precedence model: the creator can still override the setting afterwards via the "My view" controls. The existing behaviour where a creator keeps a personal override while enforcing settings for other users (pad_settings.spec.ts) is preserved — verified that whole spec still passes.

Earlier this PR tried "enforced settings win for everyone including the creator", but that broke the intentional pad_settings.spec.ts test (creator can keep authorship colors on while enforcing them off for others). This sync-personal-pref approach fixes the bug without that regression.

Test

rtl_pad_wide_enforce.spec.ts reproduces the stale-personal-cookie scenario: toggle personal RTL on/off, then set pad-wide RTL, and assert the creator's content flips to RTL (and the personal control reflects the synced value). Verified red→green and confirmed pad_settings.spec.ts still passes.

🤖 Generated with Claude Code

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[qodo-free-for-open-source-projects]

Review Summary by Qodo

Fix enforced pad-wide settings overridden by creator's personal cookies

🐞 Bug fix 🧪 Tests

Walkthroughs

Description

• Fix enforced pad-wide RTL settings being masked by creator's stale personal cookie
• Gate personal override merge on enforceSettings directly instead of
  isPadSettingsEnforcedForMe()
• Creator's pad-wide controls remain editable; lock notice not shown to them
• Add regression test reproducing stale personal cookie scenario with RTL toggle

Diagram

flowchart LR
  A["Creator toggles personal RTL"] --> B["Stale cookie rtlIsTrue=false"]
  B --> C["Set pad-wide RTL + enforce"]
  C --> D["Old: Personal cookie masks pad-wide value"]
  D --> E["Content stays LTR - bug"]
  C --> F["New: enforceSettings gates override merge"]
  F --> G["Pad-wide value is authoritative"]
  G --> H["Content flips to RTL - fixed"]

Loading

File Changes

1. src/static/js/pad.ts 🐞 Bug fix +9/-1

Gate personal overrides on enforceSettings directly

• Changed condition from isPadSettingsEnforcedForMe() to pad.padOptions.enforceSettings in
 getEffectivePadOptions()
• This ensures pad-wide values are authoritative for everyone including the creator when enforcement
 is enabled
• Personal view overrides (cookies) are no longer merged on top when enforcement is active
• Added detailed comment explaining the fix and the #7900 issue

src/static/js/pad.ts

---

2. src/tests/frontend-new/specs/rtl_pad_wide_enforce.spec.ts 🧪 Tests +55/-0

Add regression test for enforced RTL pad-wide settings

• New regression test file for issue #7900
• Tests scenario where creator toggles personal RTL on/off, creating stale cookie
• Verifies that setting pad-wide RTL + enabling enforcement makes content flip to RTL
• Confirms surrounding page/toolbar direction remains governed by UI language

src/tests/frontend-new/specs/rtl_pad_wide_enforce.spec.ts

---

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0)

Context used

✅ Tickets: 🎫 RTL Flips entire page aswell as Toolbar

1. Wrong context cookie clearing 🐞 Bug ☼ Reliability

Description

The new RTL enforcement test creates a fresh BrowserContext and clears its cookies, but then
navigates using the existing page fixture from a different context, so the cookie clear is a no-op
and the newly created context is leaked (never closed). This can make the regression test not
reliably start from a clean cookie state and can exhaust resources over the suite run.

Code

src/tests/frontend-new/specs/rtl_pad_wide_enforce.spec.ts[R14-18]

+test.beforeEach(async ({page, browser}) => {
+  const context = await browser.newContext();
+  await context.clearCookies();
+  await goToNewPad(page);
+});

Evidence

In the new test, cookies are cleared on a newly created context, but goToNewPad(page) uses the
existing page fixture (different context), so the cookie clearing does not affect the tested page
and the context is leaked. Another spec explicitly warns about this and uses
page.context().clearCookies() instead, demonstrating the correct pattern.

src/tests/frontend-new/specs/rtl_pad_wide_enforce.spec.ts[14-18]
src/tests/frontend-new/specs/inactive_color_fade.spec.ts[5-10]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`rtl_pad_wide_enforce.spec.ts` calls `browser.newContext()` and `context.clearCookies()`, but continues using the existing `page` fixture, so cookies are not cleared for the page under test. The created context is also never closed.

### Issue Context
Other frontend-new specs document this exact Playwright pitfall and use `page.context().clearCookies()` to clear cookies for the active page context.

### Fix Focus Areas
- src/tests/frontend-new/specs/rtl_pad_wide_enforce.spec.ts[14-18]

### Suggested fix
Option A (simplest, matches intent):
- Replace the beforeEach body with:
 - `await page.context().clearCookies();`
 - `await goToNewPad(page);`
- Remove the unused `browser` fixture parameter.

Option B (if you truly need a separate context):
- Create `const context = await browser.newContext(); const page = await context.newPage(); ...` and ensure `await context.close()` in `afterEach`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[qodo-free-for-open-source-projects]

1. Wrong context cookie clearing 🐞 Bug ☼ Reliability

The new RTL enforcement test creates a fresh BrowserContext and clears its cookies, but then
navigates using the existing page fixture from a different context, so the cookie clear is a no-op
and the newly created context is leaked (never closed). This can make the regression test not
reliably start from a clean cookie state and can exhaust resources over the suite run.

Agent Prompt

### Issue description
`rtl_pad_wide_enforce.spec.ts` calls `browser.newContext()` and `context.clearCookies()`, but continues using the existing `page` fixture, so cookies are not cleared for the page under test. The created context is also never closed.

### Issue Context
Other frontend-new specs document this exact Playwright pitfall and use `page.context().clearCookies()` to clear cookies for the active page context.

### Fix Focus Areas
- src/tests/frontend-new/specs/rtl_pad_wide_enforce.spec.ts[14-18]

### Suggested fix
Option A (simplest, matches intent):
- Replace the beforeEach body with:
  - `await page.context().clearCookies();`
  - `await goToNewPad(page);`
- Remove the unused `browser` fixture parameter.

Option B (if you truly need a separate context):
- Create `const context = await browser.newContext(); const page = await context.newPage(); ...` and ensure `await context.close()` in `afterEach`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools