Revive plugin-own frontend tests (the legacy mocha+helper specs)

[JohnMcLear]

Companion to #7608 / PR #7609.

PR #7609 wires up "run core's frontend tests with the /ether plugin set loaded" — catches core changes that break plugin UX. That's one direction.

The other direction — "run a plugin's own frontend tests against core" (catch core changes that break a plugin's behavior) — has been broken across the entire ecosystem since 2023.

Change type: N/A (tracking issue / scope discovery)

What's broken

Every official plugin still ships a static/tests/frontend/specs/test.js written in the legacy mocha + helper.padChrome$ jQuery-style API, e.g.:

// ep_headings2/static/tests/frontend/specs/test.js
describe('ep_headings2 - Set Heading and ensure its removed properly', function () {
  beforeEach(function (cb) { helper.newPad(cb); });
  it('Heading select has aria-label for accessibility', async function () {
    const chrome$ = helper.padChrome$;
    const $select = chrome$('#heading-selection');
    expect($select.attr('aria-label')).to.not.be(undefined);
  });
});

That format requires the in-page jQuery test runner that lived at static/index.html (the old "Etherpad jQuery frontend tests" page). That runner — and the workflow that loaded it — was removed in cc80db2d3 (2023-07-02) when the workflows were nuked en masse. Nothing has picked these specs up since.

Worse, the plugin's own CI looks like it runs them. ep_headings2/.github/workflows/frontend-tests.yml ends with:

cd src
pnpm exec playwright install chromium  --with-deps
pnpm run test-ui --project=chromium

But test-ui resolves to playwright test tests/frontend-new/specs --project=chromium, which only scans core's src/tests/frontend-new/. The plugin's static/tests/frontend/specs/test.js is never executed. So the plugin's CI green badge is misleading — it tests core's specs with the plugin loaded (== what #7609 does), not the plugin's own assertions.

Two paths to fix

A) Migrate plugin specs to playwright. Long but clean. Each plugin gets a static/tests/frontend-new/specs/*.spec.ts (or similar) and core's playwright config gets a testMatch extension that scans node_modules/ep_*/static/tests/frontend-new/specs. Migration is mechanical-ish: helper.padChrome$() → page.locator(), helper.newPad(cb) → goToNewPad(page), etc. Per-plugin work, can be paralleled across maintainers.

B) Revive the legacy jQuery runner. Faster initial fix but doubles down on a deprecated stack. We'd put back the iframe-runner page, and core's CI loads it for each plugin. Probably not worth the technical-debt mortgage.

I'd suggest A — open one tiny migration PR per plugin (maybe automate the trivial transforms), then add the testMatch glob in core. Each plugin migration can land independently.

Out of scope of this issue

The actual migration. This issue exists to make the rot visible (it's been silently present for ~3 years) and to give per-plugin migration PRs a tracking link.

🤖 Filed via PR #7609 follow-up.