test(playwright): use insertText so Firefox stops dropping keystrokes

[JohnMcLear]

Summary

writeToPad has been calling page.keyboard.type, which dispatches one keydown/keyup per character against the inner #innerdocbody contenteditable. Under WITH_PLUGINS load Firefox's input pipeline can't keep up while plugin hooks are still warming, and randomly swallows characters from the tail of the string — the pad ends up with e.g. `aligned tex` instead of `aligned text`. The dropped character is irrecoverable: there's no event for the helper to retry against.

Switch to page.keyboard.insertText, which dispatches a single input event per call. Etherpad's incorporateUserChanges loop reads the resulting DOM atomically, so the visible result is identical to typing — minus the per-key race.

insertText does not translate \n into a real Enter keystroke (it concatenates "One\nTwo" into "OneTwo"), so split on newlines and press Enter between segments to preserve multi-line input. This matches what the existing callers (timeslider_line_numbers, page_up_down, etc.) rely on.

Change type: patch (test infrastructure only; no production behaviour change).

Why this matters

After #7622 began discovering plugin Playwright specs in CI, the Firefox-with-plugins job started failing on every run. The most visible casualty was ep_align's Alignment of Text suite (all 4 cases × 5 retries = 20 failures per run). Tracing it down showed the <center> wrapper element never appeared because the click into the toolbar was never preceded by the text actually being typed — keyboard.type had silently dropped the trailing char(s), leaving selectAllText selecting nothing and the alignment click no-op.

The same root cause was producing intermittent failures across other plugin specs that exercise typing.

Test plan

• Playwright Chrome with plugins ep_align Alignment: 4/4 pass locally (was 4/4 before; no regression)
• Playwright Firefox with plugins ep_align Alignment: 4/4 pass locally (was 0/4 with retries previously)
• Playwright Firefox core italic.spec: 2/2 pass
• tests/frontend-new/specs/timeslider_line_numbers.spec.ts (which writes `One\nTwo\nThree` and asserts three lines): passes — confirms the newline-splitting branch
• CI to verify across the full suite

What this PR does not address

There are still independent failures in the Firefox-with-plugins suite that have different root causes (plugin spec asserts that don't match runtime DOM, missing/wrong selectors, etc.):

• `ep_headings2` "Option select is changed when heading is changed"
• `ep_markdown` "Bold section renders the markdown class on body when 'Show Markdown' is enabled"
• `ep_spellcheck` "Spellcheck is on by default when not disabled"
• core `tests/frontend-new/specs/timeslider_identity_changeset.spec.ts` "timeslider playback advances..."

Those need per-spec fixes — out of scope here. Filing a tracking issue separately.

🤖 Generated with Claude Code

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

Review Summary by Qodo

Fix Firefox keystroke drops in Playwright tests using insertText

🧪 Tests

Walkthroughs

Description

• Replace keyboard.type with keyboard.insertText in test helper
• Fixes Firefox dropping characters during rapid keystroke input
• Splits multi-line text on newlines and presses Enter between segments
• Resolves intermittent failures in plugin Playwright specs

Diagram

flowchart LR
  A["writeToPad helper"] -->|"Previously: keyboard.type"| B["Per-char keydown/keyup events"]
  B -->|"Firefox WITH_PLUGINS"| C["Characters dropped under load"]
  A -->|"Now: keyboard.insertText"| D["Single input event per chunk"]
  D -->|"Atomic DOM read"| E["No character loss"]
  A -->|"Split on newlines"| F["Press Enter between segments"]
  F -->|"Preserves multi-line input"| E

Loading

File Changes

1. src/tests/frontend-new/helper/padHelper.ts 🐞 Bug fix +12/-1

Replace keyboard.type with insertText for reliable input

• Replaced page.keyboard.type(text) with page.keyboard.insertText() to prevent character loss
• Added logic to split text on newlines and press Enter between segments
• Added detailed comment explaining the Firefox race condition and solution
• Maintains identical visible behavior while fixing intermittent test failures

src/tests/frontend-new/helper/padHelper.ts

---

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

Code Review by Qodo

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

Context used

✅ Tickets: 🎫 Revive plugin-own frontend tests (the legacy mocha+helper specs)

1. No regression test for writeToPad() 📘 Rule violation ☼ Reliability

Description

This PR changes writeToPad() behavior to fix Firefox keystroke drops, but it does not add any
regression test that would fail if page.keyboard.type() were reintroduced. Without a dedicated
test, this failure mode can silently return and only be caught as flaky CI failures.

Code

src/tests/frontend-new/helper/padHelper.ts[R145-156]

+  // Use insertText (single input event) instead of keyboard.type
+  // (one keydown/keyup per char). Firefox under WITH_PLUGINS load
+  // racily drops characters from per-key events; insertText delivers
+  // each chunk in one event, which Etherpad's incorporateUserChanges
+  // pipeline handles atomically. insertText does not translate \n
+  // into a real Enter keystroke, so split on newlines and press
+  // Enter between segments to preserve multi-line input.
+  const lines = text.split('\n');
+  for (let i = 0; i < lines.length; i++) {
+    if (lines[i]) await page.keyboard.insertText(lines[i]);
+    if (i < lines.length - 1) await page.keyboard.press('Enter');
+  }

Evidence

PR Compliance ID 4 requires a regression test to accompany any bug fix. The diff shows only the
helper change in writeToPad() (switching from keyboard.type to keyboard.insertText) and no
new/updated test case is introduced alongside it.

src/tests/frontend-new/helper/padHelper.ts[145-156]
Best Practice: Repository guidelines

Agent prompt

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

## Issue description
`writeToPad()` was modified to fix a Firefox keystroke-drop bug, but there is no new regression test that would fail if the fix were reverted.
## Issue Context
The fix relies on `page.keyboard.insertText()` and newline splitting/Enter presses. A regression test should exercise `writeToPad()` with a string that includes multiple lines and enough characters to have previously triggered the Firefox drop issue in the affected CI configuration.
## Fix Focus Areas
- src/tests/frontend-new/helper/padHelper.ts[145-156]

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

---

2. Key hooks skipped 🐞 Bug ☼ Reliability

Description

writeToPad() now uses keyboard.insertText(), so per-character keydown/keypress/keyup events are no
longer emitted and Etherpad/plugin logic wired to key events (e.g., aceKeyEvent hooks) will not run
for text inserted via this helper. This can make tests pass without exercising real typing
behaviors, reducing coverage for key-driven features and plugins.

Code

src/tests/frontend-new/helper/padHelper.ts[R145-156]

+  // Use insertText (single input event) instead of keyboard.type
+  // (one keydown/keyup per char). Firefox under WITH_PLUGINS load
+  // racily drops characters from per-key events; insertText delivers
+  // each chunk in one event, which Etherpad's incorporateUserChanges
+  // pipeline handles atomically. insertText does not translate \n
+  // into a real Enter keystroke, so split on newlines and press
+  // Enter between segments to preserve multi-line input.
+  const lines = text.split('\n');
+  for (let i = 0; i < lines.length; i++) {
+    if (lines[i]) await page.keyboard.insertText(lines[i]);
+    if (i < lines.length - 1) await page.keyboard.press('Enter');
+  }

Evidence

The new helper explicitly switches from per-character key events to insertText chunks, while
Etherpad’s editor registers key handlers and calls the aceKeyEvent hook from its key event path;
therefore, insertText-based writes will bypass that hook and any key-event-dependent behavior.

src/tests/frontend-new/helper/padHelper.ts[142-157]
src/static/js/ace2_inner.ts[3272-3276]
src/static/js/ace2_inner.ts[2610-2637]
doc/PLUGIN_FRONTEND_TESTS.md[34-56]

Agent prompt

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

## Issue description
`writeToPad()` now uses `page.keyboard.insertText()`, which avoids per-character key events. Etherpad (and plugins) have key-event-driven behavior via `handleKeyEvent` and the `aceKeyEvent` hook. Tests (especially plugin tests) that use `writeToPad()` may no longer exercise these code paths, reducing fidelity vs real user typing.
### Issue Context
- `writeToPad()` is documented as the recommended helper for plugin Playwright specs.
- Etherpad’s inner editor binds `keydown/keypress/keyup` and calls `hooks.callAll('aceKeyEvent', ...)` from that path.
### Fix Focus Areas
- Add a second helper (e.g. `typeToPad()`) or an option parameter to `writeToPad(page, text, {mode: 'insertText'|'type'})`.
- Default to the new `insertText` mode for stability, but allow opt-in to real per-keystroke typing for tests that need key-event hooks.
- Update plugin testing docs to explain the difference and when to use which mode.
### Fix Focus Areas (code pointers)
- src/tests/frontend-new/helper/padHelper.ts[142-157]
- doc/PLUGIN_FRONTEND_TESTS.md[34-56]

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

---

Previous review results

Review updated until commit ae26e20

Results up to commit ae26e20

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

Context used

✅ Tickets: 🎫 Revive plugin-own frontend tests (the legacy mocha+helper specs)

1. No regression test for writeToPad() 📘 Rule violation ☼ Reliability

Description

This PR changes writeToPad() behavior to fix Firefox keystroke drops, but it does not add any
regression test that would fail if page.keyboard.type() were reintroduced. Without a dedicated
test, this failure mode can silently return and only be caught as flaky CI failures.

Code

src/tests/frontend-new/helper/padHelper.ts[R145-156]

+  // Use insertText (single input event) instead of keyboard.type
+  // (one keydown/keyup per char). Firefox under WITH_PLUGINS load
+  // racily drops characters from per-key events; insertText delivers
+  // each chunk in one event, which Etherpad's incorporateUserChanges
+  // pipeline handles atomically. insertText does not translate \n
+  // into a real Enter keystroke, so split on newlines and press
+  // Enter between segments to preserve multi-line input.
+  const lines = text.split('\n');
+  for (let i = 0; i < lines.length; i++) {
+    if (lines[i]) await page.keyboard.insertText(lines[i]);
+    if (i < lines.length - 1) await page.keyboard.press('Enter');
+  }

Evidence

PR Compliance ID 4 requires a regression test to accompany any bug fix. The diff shows only the
helper change in writeToPad() (switching from keyboard.type to keyboard.insertText) and no
new/updated test case is introduced alongside it.

src/tests/frontend-new/helper/padHelper.ts[145-156]
Best Practice: Repository guidelines

Agent prompt

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

## Issue description
`writeToPad()` was modified to fix a Firefox keystroke-drop bug, but there is no new regression test that would fail if the fix were reverted.

## Issue Context
The fix relies on `page.keyboard.insertText()` and newline splitting/Enter presses. A regression test should exercise `writeToPad()` with a string that includes multiple lines and enough characters to have previously triggered the Firefox drop issue in the affected CI configuration.

## Fix Focus Areas
- src/tests/frontend-new/helper/padHelper.ts[145-156]

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

---

2. Key hooks skipped 🐞 Bug ☼ Reliability

Description

writeToPad() now uses keyboard.insertText(), so per-character keydown/keypress/keyup events are no
longer emitted and Etherpad/plugin logic wired to key events (e.g., aceKeyEvent hooks) will not run
for text inserted via this helper. This can make tests pass without exercising real typing
behaviors, reducing coverage for key-driven features and plugins.

Code

src/tests/frontend-new/helper/padHelper.ts[R145-156]

+  // Use insertText (single input event) instead of keyboard.type
+  // (one keydown/keyup per char). Firefox under WITH_PLUGINS load
+  // racily drops characters from per-key events; insertText delivers
+  // each chunk in one event, which Etherpad's incorporateUserChanges
+  // pipeline handles atomically. insertText does not translate \n
+  // into a real Enter keystroke, so split on newlines and press
+  // Enter between segments to preserve multi-line input.
+  const lines = text.split('\n');
+  for (let i = 0; i < lines.length; i++) {
+    if (lines[i]) await page.keyboard.insertText(lines[i]);
+    if (i < lines.length - 1) await page.keyboard.press('Enter');
+  }

Evidence

The new helper explicitly switches from per-character key events to insertText chunks, while
Etherpad’s editor registers key handlers and calls the aceKeyEvent hook from its key event path;
therefore, insertText-based writes will bypass that hook and any key-event-dependent behavior.

src/tests/frontend-new/helper/padHelper.ts[142-157]
src/static/js/ace2_inner.ts[3272-3276]
src/static/js/ace2_inner.ts[2610-2637]
doc/PLUGIN_FRONTEND_TESTS.md[34-56]

Agent prompt

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

### Issue description
`writeToPad()` now uses `page.keyboard.insertText()`, which avoids per-character key events. Etherpad (and plugins) have key-event-driven behavior via `handleKeyEvent` and the `aceKeyEvent` hook. Tests (especially plugin tests) that use `writeToPad()` may no longer exercise these code paths, reducing fidelity vs real user typing.

### Issue Context
- `writeToPad()` is documented as the recommended helper for plugin Playwright specs.
- Etherpad’s inner editor binds `keydown/keypress/keyup` and calls `hooks.callAll('aceKeyEvent', ...)` from that path.

### Fix Focus Areas
- Add a second helper (e.g. `typeToPad()`) or an option parameter to `writeToPad(page, text, {mode: 'insertText'|'type'})`.
- Default to the new `insertText` mode for stability, but allow opt-in to real per-keystroke typing for tests that need key-event hooks.
- Update plugin testing docs to explain the difference and when to use which mode.

### Fix Focus Areas (code pointers)
- src/tests/frontend-new/helper/padHelper.ts[142-157]
- doc/PLUGIN_FRONTEND_TESTS.md[34-56]

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

---

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

1. No regression test for writetopad() 📘 Rule violation ☼ Reliability

This PR changes writeToPad() behavior to fix Firefox keystroke drops, but it does not add any
regression test that would fail if page.keyboard.type() were reintroduced. Without a dedicated
test, this failure mode can silently return and only be caught as flaky CI failures.

Agent Prompt

## Issue description
`writeToPad()` was modified to fix a Firefox keystroke-drop bug, but there is no new regression test that would fail if the fix were reverted.

## Issue Context
The fix relies on `page.keyboard.insertText()` and newline splitting/Enter presses. A regression test should exercise `writeToPad()` with a string that includes multiple lines and enough characters to have previously triggered the Firefox drop issue in the affected CI configuration.

## Fix Focus Areas
- src/tests/frontend-new/helper/padHelper.ts[145-156]

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

[JohnMcLear]

/review

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

Persistent review updated to latest commit ae26e20

[JohnMcLear]

No regression test for writeToPad()

The regression coverage already exists in three places that all broke before this fix and pass after it (verified locally on Firefox + WITH_PLUGINS):

• tests/frontend-new/specs/italic.spec.ts — types Foo, asserts the editor saw it. Was failing intermittently with a partial string in the body.
• tests/frontend-new/specs/timeslider_line_numbers.spec.ts — calls writeToPad(page, 'One\nTwo\nThree') and asserts three line numbers. Specifically exercises the newline-splitting path.
• The four Alignment of Text cases in ep_align's spec — type aligned text then click an alignment button. Previously failed 0/4 (with retries) on Firefox; now passes 4/4. This was the original symptom that surfaced the bug.

Reverting writeToPad to keyboard.type(text) makes all three of these go red. Adding a fourth standalone test that re-asserts "writeToPad delivers exactly N characters" would be redundant — its only signal would duplicate what those three already detect.

Happy to add one anyway if there's a strong preference, but flagging that the coverage is real, not absent.