mirror of
https://github.com/ether/etherpad-lite.git
synced 2026-05-05 04:06:37 +02:00
9687 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
translatewiki.net
|
796968e517
|
Localisation updates from https://translatewiki.net. | ||
John McLear
|
57758f4aaa
|
test(ci): stronger diagnostics for silent backend-test exit (follow-up to #7663) (#7665)
* test(ci): stronger diagnostics for silent backend-test exit PR #7663 added unhandledRejection / uncaughtException handlers in common.ts. The next failure after merge (run 25279692065 - Windows without plugins, Node 24) showed mocha exiting with code 1 mid-suite 261ms after the last passing test, with NEITHER handler firing. So something more drastic is killing the process - SIGKILL, OOM, fatal native error - or mocha itself called process.exit before the JS handlers in common.ts could run. Two issues with the previous attempt: 1. Handlers in common.ts only register when a spec imports common.ts. Only 27 of 47 specs do. If a non-common spec triggers the death, handlers may never have been registered. 2. process.stderr.write is asynchronous on Windows when stderr is piped (which it is under GitHub Actions). On a hard kill the buffered line never reaches the runner log. This patch: - Moves diagnostic handlers to a dedicated tests/backend/diagnostics.ts loaded via mocha --require, so they register at startup before any spec runs. - Uses fs.writeSync(2, ...) for synchronous stderr writes that the kernel completes before returning - the line lands in the log even if the process is killed milliseconds later. - Adds beforeExit / exit / signal handlers so we can discriminate the exit mechanism: clean drain vs process.exit vs SIGKILL vs signal. - Tracks last-seen test via mocha root afterEach hook so the death point is visible in the log. The next CI failure should print enough context to identify the cause, after which we can fix the real bug and drop this file. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(diagnostics): exit(1) on uncaughtException so fatal errors fail fast Qodo flagged on PR #7665: the uncaughtException handler in tests/backend/diagnostics.ts only logged and returned. Once a handler is registered, Node no longer exits on its own. Specs that don't import tests/backend/common.ts (20 of 47) have only this handler — so a fatal error would have been swallowed and tests would limp along instead of failing fast. Mirror common.ts and call process.exit(1) after logging. --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
a0011f286d
|
test: also tag userlist_click_to_chat describe with @feature:username (#7664)
Every test in this describe block depends on each user having a settable, displayable username — clicking a userlist row reads the user's display name, prefills `@<name>` in the chat input, etc. ep_disable_change_author_name disables exactly that machinery and its CI fails the three userlist_click_to_chat cases (#86) for exactly this reason. Add the second tag so plugins declaring `disables: ["@feature:username"]` opt out via the disables contract. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
69bb1e19c5
|
feat(gdpr): author erasure (PR5 of #6701) (#7550)
* docs: PR5 GDPR author erasure design spec * docs: PR5 GDPR author erasure implementation plan * feat(gdpr): AuthorManager.anonymizeAuthor — Art. 17 erasure * test(gdpr): AuthorManager.anonymizeAuthor unit tests * feat(gdpr): REST anonymizeAuthor on API version 1.3.1 * test(gdpr): REST anonymizeAuthor end-to-end * docs(gdpr): right-to-erasure section + anonymizeAuthor example * fix(gdpr): make anonymizeAuthor resumable on partial failure Qodo review: the `erased: true` sentinel was written before the chat scrub loop, so a throw during scrub left chat messages untouched while subsequent calls short-circuited on `existing.erased` and never finished. Split the write: zero the display identity first (still hides the name), run the chat scrub, and only then stamp `erased: true` so a retry resumes the sweep. Regression test covers the partial-run → retry path. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
487842006c
|
feat(gdpr): configurable privacy banner (PR4 of #6701) (#7549)
* docs: PR4 GDPR privacy banner design spec
* docs: PR4 GDPR privacy banner implementation plan
* feat(gdpr): typed privacyBanner setting block + public getter exposure
* feat(gdpr): send privacyBanner config to the browser via clientVars
* feat(gdpr): privacy banner DOM (hidden by default)
* feat(gdpr): render privacy banner on pad load when enabled
* style(gdpr): privacy banner layout
* test+fix(gdpr): privacy banner Playwright + hidden-attr CSS override
* docs(gdpr): privacyBanner configuration section
* fix(gdpr): reject unsafe learnMoreUrl schemes
Qodo review: showPrivacyBannerIfEnabled assigned config.learnMoreUrl
directly to <a href>, so a misconfigured settings.privacyBanner.
learnMoreUrl of `javascript:alert(1)` or `data:…<script>…` would run
script on click. Validate via URL parsing and allow only http(s) /
mailto; everything else yields no link. Playwright regression guards
the four cases (javascript, data, https, mailto).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(privacy-banner): drop unneeded !important on [hidden] rule
Class+attribute selector already outranks `.privacy-banner { display: flex }`
on specificity (0,2,0 vs 0,1,0), so `!important` was redundant. Adds a
comment explaining why so a future reader doesn't put it back.
Per Sam's review on #7549.
* refactor(privacy-banner): render as a persistent gritter, not custom DOM
Drops the bespoke #privacy-banner template + ~50 lines of popup.css and
delegates to $.gritter.add({sticky: true, position: 'bottom'}). The
notice now matches every other gritter on the pad (theme variables,
shadow, animation, (X) close), sits in the bottom corner instead of
above the editor, and inherits dark-mode handling for free.
The two dismissal modes survive intact:
- dismissible: gritter closes on (X); before_close persists a flag
in localStorage so the notice is suppressed on subsequent loads.
- sticky: closes for the current session only; never persists; the
next pad load shows it again.
learnMoreUrl still goes through the same safeUrl() filter so a
javascript:/data:/vbscript: URL can't smuggle a script handler into the
anchor (Qodo's review concern remains addressed).
Tests: src/tests/frontend-new/specs/privacy_banner.spec.ts now drives
the real showPrivacyBannerIfEnabled via a __etherpad_privacyBanner__
test hook and asserts against the rendered gritter, instead of the
previous tests that mutated DOM by hand and never exercised the
function under test. Coverage adds: enabled=false short-circuit,
dismissible-flag-respected on subsequent show, sticky-ignores-flag,
sticky-close-does-not-persist, javascript: rejection, data: rejection,
and mailto: allow-list.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(privacy-banner): noreferrer + validate dismissal (Qodo)
Two follow-ups from Qodo's review on #7549:
1. The Learn-more link now sets `rel="noreferrer noopener"` (was just
`noopener`). Without `noreferrer` the browser sends the pad URL as a
Referer to the operator-configured external policy site, which leaks
pad identifiers to a third party. Matches the rel pattern already
used by pad_utils.ts.
2. `privacyBanner.dismissal` is now validated in reloadSettings(): an
unknown value falls back to 'dismissible' with a `logger.warn`, in
the same shape as the existing ipLogging validation a few lines up.
The client also guards defensively (treats anything other than the
exact string 'sticky' as 'dismissible') so that hot-reload paths
that skip the server validator can't silently degrade a typo'd
'sticky' into "no close button persisted, no localStorage suppression".
Test added: spec asserts the rel attribute, and a new test exercises
the dismissal fallback (sets dismissal:'wat', asserts the gritter is
shown, the (X) closes it, and the dismissal flag is persisted — i.e.
the unknown value is treated like 'dismissible').
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(privacy-banner): gate test hook on webdriver, align doc with sticky behavior
Two follow-ups from Qodo's second review on #7549.
Rule violation: __etherpad_privacyBanner__ was published on every pad
load even when privacyBanner.enabled was false, so the disabled-by-
default feature still added an observable global. Gate the assignment
on `navigator.webdriver` — Playwright/ChromeDriver/Selenium set this
to true; production browsers do not — so the hook is only present for
tests and the disabled path is genuinely zero-side-effect.
Bug 3 (sticky still closable): doc/privacy.md previously claimed
`dismissal: "sticky"` removes the close button, but the gritter
implementation always renders (X). Aligning the doc with reality —
sticky now means "shows on every load, but closable for the session"
— rather than adding bespoke CSS to a vanilla gritter (matches the
"don't style it differently than other gritter messages" preference
that drove the gritter migration in 906e145).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(privacy-banner): allow-list keys before sending to clientVars (Qodo)
storeSettings() merges nested objects with _.defaults() and preserves
unknown nested keys, and TypeScript's Pick<> doesn't strip at runtime.
The previous wire path forwarded settings.privacyBanner by reference
into both clientVars and getPublicSettings(), so any extra keys an
operator typed (or pasted) under privacyBanner — credentials, internal
notes, anything — would have shipped to every browser on every pad
load.
Adds getPublicPrivacyBanner() in Settings.ts that returns a literal
with only {enabled, title, body, learnMoreUrl, dismissal}, and uses it
from both leak sites (PadMessageHandler.ts clientVars and
getPublicSettings()). Single source of truth for the wire shape.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
John McLear
|
a0b85dd8b3
|
test(ci): log unhandledRejection / uncaughtException in backend test bootstrap (#7663)
Backend tests on develop have a ~22% silent failure rate (mostly Windows, sometimes Linux) where mocha exits with code 1 mid-suite, producing no test failure marker, no error, and no Mocha summary. Different exit points each run. Root cause discovery is blocked by src/tests/backend/common.ts:33, which rethrows unhandled Promise rejections as uncaught exceptions but never logs the reason first. When the rethrow happens between specs, mocha exits with code 1 and the original rejection is lost - especially on Windows, where stderr is not always flushed before abrupt exit. This patch is purely diagnostic: it writes the reason (or stack) to stderr before rethrowing, and adds a matching uncaughtException handler for the same purpose. Behavior on success is unchanged. The next CI failure will surface what is actually rejecting (DirtyDB write? plugin lifecycle? socket cleanup?), so we can fix the real cause. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
ba28241179
|
test: tag wcag_author_color describe with @feature:authorship-bg-color (#7662)
Every assertion in this describe block measures the author span's background-color against its computed text colour. Plugins that disable author background colouring entirely — e.g. ep_author_neat2, which renders authorship as coloured underlines instead — can't satisfy the WCAG bg/text contrast invariant because there's no background to measure (transparent vs. transparent yields no ratio). Tag the describe block so plugins declaring `disables: ["@feature:authorship-bg-color"]` opt out of pass 1 through the disables contract, the same way change_user_color.spec.ts already does. Unblocks ep_author_neat2 CI (its current main run fails on three wcag_author_color tests). Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
aee2b79b6a
|
test: tag rtl_url_param toggle-off specs with @feature:rtl-toggle (#7661)
* test: tag rtl_url_param toggle-off specs with @feature:rtl-toggle The two cases that require RTL to be flippable away from the plugin-forced default — `?rtl=false` overriding a prior `?rtl=true` and a no-param reload falling back to the cookie — are exactly what ep_right_to_left intentionally disables. Tag them so the plugin can declare `disables: ["@feature:rtl-toggle"]` and pass the disables contract's honesty check. Also list the new tag (and the previously omitted @feature:line-numbers) in doc/PLUGIN_FEATURE_DISABLES.md. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test: also tag chat title-bar layout spec with @feature:rtl-toggle The leftGap/rightGap symmetry assertion in this test is LTR-only: colibris ships a one-sided #titlebar padding rule (the existing asymmetric pad is fine in LTR because the buttons are on the right where the larger pad sits) that throws gaps apart by ~170px when body[dir=rtl] reverses the flex item order. Without a fix to colibris's chat header padding (out of scope here), plugins that force RTL on can't pass this assertion. Add the second tag so they can declare the disable instead of false-failing it. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
dependabot[bot]
|
0803791acc
|
build(deps-dev): bump the dev-dependencies group across 1 directory with 2 updates (#7653)
Bumps the dev-dependencies group with 2 updates in the / directory: [eslint](https://github.com/eslint/eslint) and [react-hook-form](https://github.com/react-hook-form/react-hook-form). Updates `eslint` from 10.2.1 to 10.3.0 - [Release notes](https://github.com/eslint/eslint/releases) - [Commits](https://github.com/eslint/eslint/compare/v10.2.1...v10.3.0) Updates `react-hook-form` from 7.74.0 to 7.75.0 - [Release notes](https://github.com/react-hook-form/react-hook-form/releases) - [Changelog](https://github.com/react-hook-form/react-hook-form/blob/master/CHANGELOG.md) - [Commits](https://github.com/react-hook-form/react-hook-form/compare/v7.74.0...v7.75.0) --- updated-dependencies: - dependency-name: eslint dependency-version: 10.3.0 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: dev-dependencies - dependency-name: react-hook-form dependency-version: 7.75.0 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: dev-dependencies ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
John McLear
|
49bc33f019
|
feat(gdpr): HttpOnly author-token cookie (PR3 of #6701) (#7548)
* docs: PR3 GDPR anonymous identity hardening design spec
* docs: PR3 GDPR anon identity implementation plan
* feat(gdpr): ensureAuthorTokenCookie helper — HttpOnly server-set author token
* feat(gdpr): set HttpOnly author-token cookie from the pad routes
* feat(gdpr): read author token from cookie first, keep message.token fallback
* feat(gdpr): stop generating the author token client-side
* test(gdpr): server sets + reuses the HttpOnly author-token cookie
* fix+test(gdpr): parse token cookie from handshake Cookie header
socket.io handshake doesn't run cookie-parser, so socket.request.cookies
is undefined. Parse the Cookie header directly in handleClientReady so
the HttpOnly token actually resolves. Playwright spec covers HttpOnly
attribute, reload-stability, and context-isolation.
* docs(gdpr): token cookie is now HttpOnly + server-set
* fix(gdpr): close two HttpOnly token bypasses
Qodo review:
- Timeslider still ran the pre-PR3 JS-cookie path: it read
Cookies.get('${cp}token') (which HttpOnly hides), then generated a
fresh plaintext token and overwrote the server's HttpOnly cookie with
it, and sent token in every socket message. Strip the token read/
write entirely from timeslider.ts and from the outgoing message
shape; the server reads the cookie off the socket.io handshake just
like on /p/:pad.
- tokenTransfer re-issued the author cookie without HttpOnly, undoing
the hardening the first time a user transferred a session. Re-set
it as HttpOnly + Secure (on HTTPS) + SameSite=Lax. Also stop
trusting the body-supplied token on POST: read it off req.cookies
server-side so the client never needs JS access to the token.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
John McLear
|
9014d3a7c4
|
fix(colors): pick WCAG-higher-contrast text for author colors (#7565)
* feat(colors): clamp author backgrounds to WCAG 2.1 AA on render Fixes #7377. Authors can pick any color via the color picker, so a user who chooses a dark red ends up with black text rendered on a background that fails WCAG 2.1 AA (4.5:1) — unreadable, but there is no way for *viewers* to remediate since they cannot change another author's color. Screenshot in the issue shows exactly this. This PR lands a viewer-side clamp. For each author background, if neither black nor white text would satisfy the target contrast ratio, the bg is iteratively blended toward white until black text does. The author's stored color is untouched — turning off the new padOptions.enforceReadableAuthorColors flag restores the raw colors immediately. New helpers in src/static/js/colorutils.ts: - relativeLuminance(triple) — WCAG 2.1 relative-luminance formula - contrastRatio(c1, c2) — in [1, 21]; >=4.5 = AA, >=7.0 = AAA - ensureReadableBackground(hex, minContrast = 4.5) — returns a hex that meets minContrast against black text, preserving hue Wire-up: - src/static/js/ace2_inner.ts (setAuthorStyle): pass bgcolor through ensureReadableBackground before picking text color. Gated on padOptions.enforceReadableAuthorColors (default true). Guarded by colorutils.isCssHex so the few non-hex values (CSS vars, etc.) skip the clamp and pass through unchanged. - Settings.ts / settings.json.template / settings.json.docker: new padOptions.enforceReadableAuthorColors flag, default true, with a matching PAD_OPTIONS_ENFORCE_READABLE_AUTHOR_COLORS env var in the docker template. - doc/docker.md: env-var row. - src/tests/backend/specs/colorutils.ts: new unit coverage for the three new helpers, including the exact #cc0000 failure case from the issue screenshot. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(7377): simplify — just pick higher-contrast text, drop bg clamp First iteration added an iterative bg-lightening helper (ensureReadableBackground) gated by a new padOptions flag. CI caught the correct simpler framing: because WCAG contrast is symmetric in [1, 21], at least one of black/white always clears AA (4.5:1) for any sRGB colour. The real bug was that the pre-fix textColorFromBackgroundColor used a plain-luminosity cutoff (< 0.5 → white), which produced sub-AA combinations like white-on-red (#ff0000) at 4.0:1. Reduce the PR to the minimal surface: - colorutils.textColorFromBackgroundColor now picks whichever of black/white has the higher WCAG contrast ratio against the bg. - colorutils.relativeLuminance and colorutils.contrastRatio are kept as reusable building blocks; ensureReadableBackground is dropped (no caller needed it once text selection was fixed). - ace2_inner.ts setAuthorStyle no longer needs the opt-in flag or the isCssHex guard — the helper handles every input its caller already passes. - padOptions.enforceReadableAuthorColors setting reverted along with settings.json.template, settings.json.docker, and doc/docker.md. - Tests replaced: instead of asserting the bg gets lightened, assert that the chosen text colour clears AA for every primary. Covers the exact #ff0000 failure case from the issue screenshot. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(7377): assert relative-contrast invariant, not absolute AA Pure primaries like #ff0000 cannot clear WCAG AA (4.5:1) against either #222 or #fff — the best either can do is ~4.0:1. No text-colour choice alone fixes that; bg clamping would be a separate concern. The test should therefore verify the *real* invariant: the chosen text colour must produce the higher contrast of the two options, regardless of whether that contrast clears any absolute threshold. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(7377): compare against rendered #222/#fff, not pure black/white First cut of textColorFromBackgroundColor computed contrast against pure black (L=0) and pure white (L=1), then returned the concrete #222/#fff the pad actually renders with. For some mid-saturation backgrounds the two comparisons disagreed — e.g. #ff0000: vs pure black = 5.25 → pick black → render #222 → actual 3.98 vs pure white = 4.00 → would-render #fff → actual 4.00 The helper picked the wrong option because it compared against the wrong target. Compare against the actual rendered colours so the returned text colour is genuinely the higher-contrast choice. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(7377): pick unambiguous colibris test bgs #ff0000 lives right at the boundary for the two text choices (4.00 vs 3.98), so the test for colibris-skin mapping was entangled with the border-case selector pick. Use #ffeedd (clearly light → dark text wins) and #111111 (clearly dark → light text wins) so the test isolates the skin mapping from the tie-breaking logic. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(7377): use rendered text colour + clamp bg to actually meet AA Local repro of the issue exposed two real bugs in the previous fix: 1. textColorFromBackgroundColor compared bg against a hardcoded #222 — but in the colibris skin --super-dark-color resolves to #485365. For the issue's exact case (#9AB3FA author bg) the selector returned var(--super-dark-color) thinking it was getting a 7.7:1 ratio, while the browser actually rendered 3.78:1 — identical to what the issue screenshot reported. This PR's previous behaviour on the issue's inputs was unchanged from the pre-fix. 2. For mid-saturation pastels (#9AB3FA) and pure primaries (#ff0000) neither rendered dark nor white text can clear AA. Text-colour selection alone genuinely cannot fix this band; the ensureReadable bg clamp dropped in ce0c5c283 was load-bearing. Changes: - colorutils.ts: per-skin SKIN_TEXT_COLORS table with darkRef/lightRef matching what the browser actually paints (colibris #485365, default #222). Re-introduces ensureReadableBackground, but skin-aware and symmetric — blends bg toward white or black depending on which text colour wins, so it works for both light and dark backgrounds. - ace2_inner.ts: setAuthorStyle runs the bg through the clamp before picking text colour. Gated on padOptions.enforceReadableAuthorColors (default true). - Settings.ts / settings.json.template / settings.json.docker / doc/docker.md: padOption + PAD_OPTIONS_ENFORCE_READABLE_AUTHOR_COLORS env var. - tests: failing-then-green coverage for the issue's exact case (#9AB3FA + colibris), the previously-impossible #ff0000, the no-mutation case, non-hex pass-through, and a sweep over primaries. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(7377): add e2e DOM-contrast spec + extra unit cases The previous coverage was unit-only, which is what let the original wrong- reference-colour bug ship — the algorithm tests were green but nothing exercised what the browser actually paints. New coverage: Playwright (src/tests/frontend-new/specs/wcag_author_color.spec.ts): - Sets the user's colour to the issue's exact #9AB3FA, types text, reads the rendered author span's computed bg + colour from the inner frame, and asserts the WCAG ratio between the two is >= 4.5. Repeated for #ff0000 (the other historically-failing case). - Asserts #ffeedd (already AA-friendly) is rendered unchanged — guards against the clamp mutating colours that don't need it. Backend additions (src/tests/backend/specs/colorutils.ts): - Symmetric-clamp test: dark mid-saturation bg where light text wins, the clamp must darken (not lighten). Direction check via relativeLuminance. - minContrast parameter: AAA (7.0) must produce more clamping than AA. - Output shape: result must be a parseable hex string (round-trip safe). - Short-hex (#abc) input is accepted and normalised. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
25c43140bc
|
feat(userlist): click a user to open chat with @<name> prefilled (#7660)
* feat(userlist): click a user to open chat with @<name> prefilled
Newcomers to a multi-user pad regularly fail to discover the chat
panel and the @-mention convention. Make the user list itself the
discovery affordance: clicking another user's row opens chat (if
hidden) and prefills the input with "@<their_name> ", ready to send.
The skin gets a small visual cue — pointer cursor on .usertdname and
an underline on hover — so the affordance is visible without
requiring a redesign. The color swatch keeps its own click semantics
(color picker), so the swatch cell is excluded from the new handler.
To let bot/AI plugins substitute their trigger string for an
otherwise-useless @-mention of the bot's display name (e.g.
"@AI Assistant" → "@ai"), this adds a new client-side hook,
chatPrefillFromUser, that takes {authorId, name, prefill} and lets
the first plugin to return a non-empty string override the default
prefill. Documented in doc/api/hooks_client-side.md alongside
chatSendMessage.
Plugin errors in the hook are caught — a misbehaving plugin can't
break the click. If chat is hidden by pad settings, chat.show() is
a no-op and the click effectively does nothing, which matches the
existing behavior of "no chat means no chat-related affordances".
The new prefill never clobbers a real partial message in the input;
if the user was mid-typing something, the @-mention is appended
rather than replacing.
* fix(userlist): don't steal rename focus + add Playwright coverage
Two follow-ups on review of the click-to-chat handler:
1. Bug (Qodo, correctness): clicking the rename <input> on an unnamed
user's row triggered the new row handler, which then focused
#chatinput and made it impossible to name unnamed users from the
user list. Add an early-return that skips form controls inside
the row (input/textarea/select/button/a/[contenteditable=true]).
The swatch was already excluded; this widens the same idea to
anything that's interactive on its own merits.
2. Test coverage: add a frontend Playwright spec
(userlist_click_to_chat.spec.ts) covering the supported flows
and the new regression:
- clicking another named user opens chat and prefills "@<name> "
- clicking the swatch opens color picker, not chat
- clicking the rename <input> on an unnamed user keeps focus
on the input (regression test for the bug above)
- partial chat message is preserved when prefilling
* test: stabilise the partial-message preservation case
The 'partial message in chat input is preserved when prefilling'
case was flaking on CI. Three small changes:
- Seed the chat input with fill() rather than click() + keyboard.type().
Earlier the test was racing chat.focus()'s own setTimeout(100) — when
the keyboard.type started before that timer fired, the typing landed
in whatever element had focus at the time, which wasn't always the
chat input. fill() bypasses focus state entirely.
- Wait for the chat box to be visible before filling, so we don't race
the chaticon click handler.
- Replace the two sequential expect/wait pairs after the daveRow click
with one waitForFunction that asserts both 'hi there' and '@Dave' are
in the input together. The prefill is async (setTimeout(50) inside
the click handler), so a combined wait is more reliable than checking
one piece, then snapshotting and asserting the other.
The other three cases in this file passed unchanged on CI; only this
fourth one was racy.
* fix: don't commit local .claude worktrees / var state
These were accidentally added in ffe947706 by an over-broad git add -A.
Both paths are workspace-local and unrelated to this PR.
|
||
|
John McLear
|
e0a989094d
|
feat(colors): add padOptions.fadeInactiveAuthorColors with toolbar UI (#7554)
Adds a new pad option `fadeInactiveAuthorColors` (default `true`) that controls whether each author's caret/background fades toward white as they go inactive. Configurable server-side (`settings.json` / `PAD_OPTIONS_FADE_INACTIVE_AUTHOR_COLORS`), per-pad in the Pad Settings panel, per-user in the My View panel, or via `?fadeInactiveAuthorColors=false`. Disabling the fade is useful on busy pads where every faded author visually counts as a second on-screen color (a 30-author pad becomes a 60-color pad), or when inactivity tracking is undesirable for whatever reason. Closes #7138. |
||
|
John McLear
|
6e3f929896
|
test: tag two line-numbers-touching pad_settings specs with @feature:line-numbers (#7658)
Surfaced by ep_hide_line_numbers' red main. Two pad_settings specs
use `expect(...).not.toHaveClass(/line-numbers-hidden/)` to verify
the line-number gutter is visible by default before settings flip
it on, but plugins that hide line numbers (ep_hide_line_numbers
sets `pad.changeViewOption('showLineNumbers', false)` in postAceInit)
keep that class on the body for the entire pad lifetime.
Tag the two affected specs with @feature:line-numbers so plugins
that hide line numbers can declare `disables: ["@feature:line-numbers"]`
in ep.json and have these excluded from pass-1 regression while
still failing pass-2 honesty (plugin must actually keep them hidden).
Companion to the existing tag set (@feature:chat, @feature:username,
@feature:clear-authorship, @feature:error-gritter,
@feature:authorship-bg-color). See doc/PLUGIN_FEATURE_DISABLES.md.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
John McLear
|
0be8afc1ac
|
test: add @feature:authorship-bg-color tag for plugins that re-render authorship (#7657)
Plugins like ep_author_neat2 swap Etherpad's coloured-background authorship indicator for an underline. Their README is explicit about this; their main is red on the disables-aware test runner because change_user_color.spec.ts:59 hard-asserts the chat <p>'s background-color matches the user's colour, which a non-background rendering legitimately won't satisfy. Add a second tag (@feature:authorship-bg-color) alongside the existing @feature:chat so plugins that swap rendering can declare "disables": ["@feature:authorship-bg-color"] and have this single spec excluded from pass-1 regression while still running pass-2 honesty (the bg-color assertion fails under the plugin → contract honoured). Multi-tag: ep_disable_chat keeps excluding it via @feature:chat; ep_author_neat2 excludes it via @feature:authorship-bg-color. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
02e37e0112
|
feat(packaging): publish Etherpad as a Snap (#7558)
* feat(packaging): publish Etherpad as a Snap Adds first-class Snap packaging so Ubuntu / snapd users can install via `sudo snap install etherpad-lite`. - snap/snapcraft.yaml — core24, strict confinement, builds with pnpm against a pinned Node.js 22 runtime. Version is auto-derived from src/package.json so `snap info` tracks upstream release numbering. - snap/local/bin/etherpad-service — launch wrapper that seeds $SNAP_COMMON/etc/settings.json on first run (rewriting the default dirty-DB path to a writable $SNAP_COMMON location) and execs Etherpad via `node --import tsx/esm`. - snap/local/bin/etherpad-healthcheck-wrapper — HTTP probe for external supervisors, falling back to Node if curl isn't staged. - snap/local/bin/etherpad-cli — thin passthrough to Etherpad's bin/ scripts (importSqlFile, checkPad, etc.). - snap/hooks/configure — exposes `snap set etherpad-lite port=<n>` and `ip=<addr>` with validation, restarts the service when running. - snap/README.md — build / install / configure / publish instructions. - .github/workflows/snap-publish.yml — builds on every v* tag, uploads a short-lived artifact, publishes to `edge`, and then promotes to `stable` through a manually-approved GitHub Environment. Requires a one-time `snapcraft register etherpad-lite` plus provisioning of the `SNAPCRAFT_STORE_CREDENTIALS` repo secret (instructions inline). Pad data (dirty DB, logs) lives in /var/snap/etherpad-lite/common/ and survives snap refreshes. The read-only $SNAP squashfs is never written to at runtime. Refs #7529 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(snap): pass --settings flag, env-subst ip/port, 2-space indent Addresses Qodo review feedback on #7558: 1. Settings file ignored: Etherpad's Settings loader reads `argv.settings`, not the `EP_SETTINGS` env var. Without `--settings`, the launcher's seeded $SNAP_COMMON/etc/settings.json is never loaded; Etherpad falls back to <install-root>/settings.json, which lives on the read-only squashfs — so the default dirty-DB path ends up unwritable and the daemon fails to persist pads. Fix: pass `--settings "${SETTINGS}"` to node; drop the EP_SETTINGS export. 2. `snap set` overrides were no-ops: the seeded settings.json carries the template's literal `"ip": "0.0.0.0"` / `"port": 9001` values, which override the env-based defaults Etherpad exposes via ${…} substitution. Users following the README saw the listener stay put after `snap set etherpad-lite port=…`. Fix: after copying the template on first run, rewrite the top-level `ip` and `port` lines to `"${IP:0.0.0.0}"` / `"${PORT:9001}"`. Use `0,/…/` anchors so the `dbSettings.port` entry further down stays literal. 3. Indentation: reflow the new shell scripts from 4-space to 2-space to match the repo style rule. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(snap): default seeded settings to sqlite, not dirty settings.json.template's own comment says dirty is for testing only. A Snap install is the "not testing" case — shipping it by default means every `sudo snap install etherpad-lite` starts on a DB the project explicitly recommends against. Rewrite the postinstall sed to switch dbType: "dirty" → "sqlite" and point filename at $SNAP_COMMON/var/etherpad.db. sqlite is already shipped in-tree via ueberdb2 → rusty-store-kv (prebuilt napi-rs binary, no build deps), so this works under strict confinement with zero snap.yaml changes. Only affects first-run seeding; existing $SNAP_COMMON/etc/settings.json is never touched on refresh. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(snap): rename to "etherpad", glob tag filter, harden cli - Snap is registered as `etherpad` (the project's only name) — drops the legacy `etherpad-lite` from the name, app, paths, install dir, configure hook, README and workflow artifact. The daemon app shares the snap name, so `snap install etherpad` exposes a bare `etherpad` command; the bin/ passthrough is now `etherpad.cli`. - snap-publish.yml: GitHub Actions tag filters use globs, not regex. The prior `v?[0-9]+.[0-9]+.[0-9]+` pattern would never match a real release tag (Qodo review). Replace with two glob entries covering `vX.Y.Z` and `X.Y.Z`. - etherpad-cli: reject path-traversal in the `<bin-script>` arg (anything containing `/`, `..`, or empty) and add a default `*)` case so files with unsupported extensions fail loud instead of silently exiting 0 (Qodo review). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(snap): unbreak build — refresh corepack, drop pnpm prune Two issues hit on the first real `snapcraft pack` of this recipe: - `corepack prepare pnpm@10.33.0 --activate` failed with `Cannot find matching keyid` because Node 22.12's bundled corepack ships a stale signing-key list and rejects newer pnpm releases (nodejs/corepack#612). Refresh corepack itself via npm before preparing pnpm. - `pnpm prune --prod` is interactive on workspace projects: it asks "The modules directories will be removed and reinstalled from scratch. Proceed? (Y/n)" and deadlocks on stdin under sudo + tee. Replace it with the explicit "wipe node_modules + prod reinstall" pattern, which is non-interactive, faster (pnpm resolves the prod graph from its CAS cache), and byte-identical in result. Verified locally: `snapcraft pack --destructive-mode` produces `etherpad_2.6.1_amd64.snap` end-to-end in ~3 min. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(snap): unbreak runtime — tsx resolution, var/ writability, env Three runtime crashes surfaced when actually installing the built snap under strict confinement. Fixed each, plus a smoke-test script. - `tsx` is in the `src` workspace's node_modules under pnpm hoisting, not at the snap install root. The wrapper now `cd "${APP_DIR}/src"` and uses bare `--import tsx` (matching `bin/cleanRun.sh`); the prior `--import tsx/esm` triggered ERR_REQUIRE_CYCLE on Etherpad's mixed CJS/ESM source tree. - Etherpad's plugin installer writes `var/installed_plugins.json` via __dirname-relative paths, which resolve to absolute paths inside the read-only snap squashfs (EROFS). snap layouts can't intercept paths inside `$SNAP`, so replace the shipped `var/` dir with a symlink to `/var/snap/etherpad/common/etherpad-app-var/` (auto-created by the wrapper on first run). Persistent state survives `snap refresh`. - Drop the unused `EP_SETTINGS` and `EP_DATA_DIR` env vars from the app's `environment:` block. Etherpad's settings loader doesn't read them — it reads `argv.settings`, which the wrapper already passes via `--settings`. They were producing `[WARN] settings - Unknown Setting` noise on every start. Add `snap/tests/smoke.sh`: rebuild + install + configure test port 9003 + assert listener + curl /health + tail logs. Local verified output: HTTP 200, body {"status":"pass","releaseId":"2.6.1"}, server logs `Etherpad is running` on `http://0.0.0.0:9003/`. .gitignore now excludes destructive-mode build outputs (parts/, stage/, prime/, .craft/, *.snap). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(snap): wrapper unit tests, PR CI build, expanded docs Coverage in snap/tests/ (47 assertions, ~5s, no snapd/sudo/network): - test-snapcraft-yaml.sh: required keys, name validity, daemon-app matches snap name, no etherpad-lite regression, env-var whitelist. - test-cli.sh: path-traversal rejection, .ts/.sh dispatch, default-case rejection, no-args usage. - test-configure.sh: port (1-65535) and ip (v4/v6) validation via mocked snapctl. - test-service-bootstrap.sh: first-run seeding from settings.json.template, sed rewrite of dbType/filename/ip/port, writable-dir creation, snapctl override propagation to node env, idempotency on second run, default fallbacks. - run-all.sh: bash -n syntax check on every wrapper + hook, then sources each test file and reports totals. All assertions use port 9003 (project test convention). CI in .github/workflows/snap-build.yml: - Triggers on PR / push-to-develop touching snap/, settings.json.template, or the workflow itself. - Job 1 wrapper-tests: runs run-all.sh. - Job 2 snap-pack: snapcraft pack --destructive-mode, uploads .snap as PR artifact for sideload. - Stays separate from snap-publish.yml (tag-triggered, store-bound). snap/README.md fully rewritten: - User-facing usage, install, configure - Architecture: file layout, var/-symlink rationale, settings.json rewrite rationale, double-pnpm-install rationale, daemon-name-shares- snap-name rationale - Three test layers with exactly when/why to run each - Dev workflow loop - Publishing maintainer setup - Troubleshooting for every failure mode hit during this PR (EROFS, tsx not found, ERR_REQUIRE_CYCLE, snap-store-down, pnpm prune hang) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(snap): replace dead snapcraft.io/docs/releasing-to-the-snap-store link That URL now 404s. Point at the canonical documentation.ubuntu.com locations instead, broken out into the specific pages a maintainer actually needs: - Register a snap (to claim the name) - snapcraft export-login (to generate the SNAPCRAFT_STORE_CREDENTIALS secret) - Publishing how-to index (root index for everything else) Same fix in the snap-publish.yml header comment. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
983aec5b2f
|
test: tag two chat-toggle pad_settings specs with @feature:chat (#7655)
Surfaced by ep_disable_chat#75 — the disables-aware test runner ran pass 1 (regression) and these two tests failed because they click label[for="options-disablechat"], which ep_disable_chat hides as intended. Tagging them brings them into pass 2 (honesty) where they're expected to fail under the plugin, instead of pass 1 where they shouldn't run. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
ea3032c079
|
i18n + a11y for admin disables warning (review feedback) (#7652)
Replace the hardcoded "Disables:" label and the inline title attribute with proper i18n keys (admin_plugins.disables.label, admin_plugins.disables.warning_title) and add role="alert" so screen readers announce the warning instead of treating it as visual noise. Per user review on #7649: "we should display it as a warning only if a plugin disables a test... Also i18n!!! Always remember to do i18n." Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
56596e21bb
|
fix(test): disables helper auto-detect must follow symlinks (#7654)
ep_disable_chat#75 ran with `disables: ["@feature:chat"]` declared in
ep.json but the helper printed "No 'disables' declared — running
standard test suite" and exec'd a vanilla `playwright test`, with
@feature:chat-tagged tests running anyway and timing out one by one.
Root cause: the auto-detect used `find -maxdepth 3 plugin_packages/
-name ep.json -not -path '*/.versions/*'`. Live-plugin-manager
installs plugins under `plugin_packages/.versions/<name>@<ver>/`
and exposes them as symlinks at `plugin_packages/ep_<name>`. find(1)
doesn't follow symlinks by default, so:
- the .versions/ ep.json was excluded by -not -path
- the symlink at plugin_packages/ep_<name> was visited but find
didn't recurse into it because it's a symlink, not a real dir
=> 0 candidates found, helper falls through to standard mode.
Switch to a shell glob with `-f` membership tests, which resolve
symlinks correctly. Verified against a synthetic install: the helper
now finds the disables list and prints "Plugin disables: @feature:chat"
before running pass 1.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
John McLear
|
6900767934
|
fix(test): make disables helper's pass 2 fail-fast (#7651)
Pass 2 was running every test tagged with a disabled feature to completion. For a busy tag like @feature:chat (12 tests) with the default 90s per-test timeout, that's 10+ minutes of expected failures piling up — ep_disable_chat's first PR #75 ran 14+ min before being cancelled. Pass 2 only needs *evidence* the feature is gone — one failing tagged test is enough. Add: --max-failures=1 stop on the first failure (~30s vs ~10min) --timeout=30000 cap any single test at 30s --retries=0 already there, but flagged: CI retry default (up to 5 with WITH_PLUGINS=1) would retry an "expected failure" multiple times. Worst case (first tagged test happens to pass): we wait for the second one to fail, ~60s. Still bounded. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
056ae7cd59
|
fix(test): make disables helper's pass 2 fail-fast (#7650)
Pass 2 was running every test tagged with a disabled feature to completion. For a busy tag like @feature:chat (12 tests) with the default 90s per-test timeout, that's 10+ minutes of expected failures piling up — ep_disable_chat's first PR #75 ran 14+ min before being cancelled. Pass 2 only needs *evidence* the feature is gone — one failing tagged test is enough. Add: --max-failures=1 stop on the first failure (~30s vs ~10min) --timeout=30000 cap any single test at 30s --retries=0 already there, but flagged: CI retry default (up to 5 with WITH_PLUGINS=1) would retry an "expected failure" multiple times. Worst case (first tagged test happens to pass): we wait for the second one to fail, ~60s. Still bounded. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
e028016296
|
feat(admin): surface ep.json disables in /admin plugin browser (#7649)
Companion to ether/ether.github.com#395 — the admin UI's "available plugins" listing now also renders the plugin's declared `disables` (see doc/PLUGIN_FEATURE_DISABLES.md) so an operator about to click Install sees the same warning as a user browsing etherpad.org/plugins: "Disables: chat". - src/node/types/PackageInfo.ts: optional `disables?: string[]` on the registry payload type. - admin/src/pages/Plugin.ts: same on the admin-side PluginDef. - admin/src/pages/HomePage.tsx: render an amber callout under the description when `disables` is present and non-empty. Plugins without a disables field render unchanged. The plugin-registry build pipeline still has to start surfacing `disables` from ep.json into plugins.json/plugins.viewer.json — until that lands, the new callout no-ops everywhere, which is fine. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
b769ab6e54
|
feat(test): feature tags + declared-disables contract for opt-out plugins (#7648)
Plugins that intentionally remove a baseline Etherpad feature
(ep_disable_chat, ep_disable_change_author_name, ep_disable_error_messages,
ep_disable_reset_authorship_colours) currently break core tests for the
removed feature. Their main branches are red, their auto-publish gates
never fire, and Dependabot PRs pile up.
The temptation is to give these plugins an "opt-out of these tests"
flag — but that's a self-serving attestation: a plugin can claim "I
just disable chat, ignore those tests" and quietly break unrelated
functionality on the user's install. etherpad.org/plugins would still
show it green.
This commit introduces a small declared-disables contract that closes
that gap:
1. Core specs grow @feature:* Playwright tags. Initial set:
@feature:chat, @feature:username, @feature:clear-authorship,
@feature:error-gritter. Tags are added test-by-test where the
test exercises a single feature, so the contract stays precise.
2. Plugins declare which feature tags they disable in their ep.json:
{ "name": "ep_disable_chat", "disables": ["@feature:chat"], ... }
3. bin/run-frontend-tests-with-disables.sh enforces the contract via
two passes:
- Pass 1 (regression): every test NOT in the disabled list must
pass. Catches plugins that break things they don't claim to.
- Pass 2 (honesty): every test that IS in the disabled list
must FAIL. Catches plugins that lie about disabling features
they don't actually disable, and stops them from grep-inverting
arbitrary unrelated tests.
4. doc/PLUGIN_FEATURE_DISABLES.md walks the design and migration.
The disables list is in ep.json (publicly visible), so etherpad.org/plugins
can surface "this plugin disables: chat" alongside the green CI badge —
users see what they're losing before they install.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
John McLear
|
90fd9b15b1
|
fix(plugins): updatePlugins.sh actually updates installed plugins (closes #6670) (#7644)
* fix(plugins): updatePlugins.sh actually updates installed plugins (#6670) bin/updatePlugins.sh detected outdated plugins by running `pnpm --filter ep_etherpad-lite outdated --depth=0`, but installed plugins are not registered in src/package.json — bin/plugins.ts adds them via linkInstaller.installPlugin which writes to src/plugin_packages/.versions/<name>@<version>/ and tracks the result in var/installed_plugins.json. pnpm has no view of them, so `outdated` returns empty and the script always reported "All plugins are up-to-date" even when newer versions existed on the registry. PR #7468 fixed npm→pnpm and install→update but kept the same broken detection mechanism, which is why the issue stayed open after that PR landed. Read the plugin list from var/installed_plugins.json instead, then re-invoke linkInstaller.installPlugin(name) for each entry. Calling the installer without a version pin resolves the registry-latest and overwrites the existing pinned copy, so an outdated plugin is brought to head while plugins already at latest are no-ops apart from the pnpm cache hit. Add an `update`/`up` action to bin/plugins.ts so users can also run `pnpm run plugins update` directly, mirroring the existing install/remove/list actions. updatePlugins.sh becomes a one-line wrapper for backwards compatibility. Reproduction (verified): pnpm run install-plugins ep_markdown@11.0.5 # latest is 11.0.18 ./bin/updatePlugins.sh # → 11.0.18 Edge cases tested: no plugins installed, missing installed_plugins.json, already-at-latest re-run. Closes #6670. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(plugins): validate ep_ prefix and dedupe + add regression test Qodo flagged two issues on the original update() addition: 1. Security — update() trusted every name in var/installed_plugins.json, so a corrupted or hand-edited manifest could coerce the script into installing arbitrary npm packages. pluginfw/plugins.getPackages already gates on the ep_ prefix; mirror that gate here. 2. Reliability — no automated regression test, so a future refactor could silently bring back the broken behaviour. Extract the safe-name filter to filterUpdatablePluginNames in bin/commonPlugins.ts (pure, side-effect-free, prefix configurable, also de-duplicates repeats so a duplicated entry installs once). Use it from plugins.ts update(). Add src/tests/backend/specs/filterUpdatablePluginNames.ts covering: keep prefixed names, drop ep_etherpad-lite, reject non-prefixed entries, de-dupe repeats, tolerate missing/null/non-string name fields, empty input, custom prefix. Manually verified end-to-end on a live install: an installed_plugins.json containing ep_markdown@11.0.5, a duplicate ep_markdown, and a "malicious-package" entry runs `Updating plugins to latest from registry: ep_markdown` (only) and ep_markdown ends up at 11.0.18 — the bad entries are silently filtered out. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
d8befd8491
|
test(ci): widen timing windows for flaky SessionStore + socket.io tests (#7647)
* test: widen timing windows for flaky CI tests on slow runners
SessionStore.ts and socketio.ts dominate develop CI failures (~25–40% of
recent runs). Both fail due to race conditions on slow Windows / loaded
Linux runners — not logic bugs.
SessionStore tests configure session expiry windows of 100ms and then
sleep 110ms before asserting. On a slow runner, the wall-clock between
`set()` and the assertion can exceed 100ms, the timeout in
`SessionStore._updateExpirations()` then sees `exp.real <= now` and
calls `_destroy()`, deleting the DB record before the assertion runs.
The test then reads `null` / `undefined` instead of the expected JSON.
Tripling each affected window (100→300, 110→330, 200→600) keeps the
relative timing semantics identical while leaving enough headroom for
a slow CI runner. Local run is +3s on this spec; cheap insurance for
the global flake rate.
`waitForSocketEvent` in tests/backend/common.ts uses a 1s timeout for
socket.io message round-trips. The socket.io handshake + auth +
CLIENT_READY can exceed 1s on a slow runner; bumped to 5s.
The most-failing tests this addresses:
- SessionStore: get of record from previous run (not yet expired)
- SessionStore: external expiration update is picked up
- SessionStore: shutdown cancels timeouts
- socketio: !authn anonymous cookie /p/pad -> 200, ok
- socketio: authn user /p/pad -> 200, ok
- clientvar_rev_consistency: CLIENT_VARS stays consistent under
concurrent edits during handshake
All 28 SessionStore + 33 socketio tests pass locally.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* test: address Qodo PR feedback — configurable socket timeout, polling for cleanup
Both items raised in Qodo's review of #7647.
1) Hardcoded 5s socket wait
waitForSocketEvent() now takes an optional timeoutMs (default 1000ms,
matching pre-PR behaviour). Only the known-slow connect() and
handshake() paths pass 5000ms — they're the ones blowing the 1s budget
on loaded CI runners. Per-message waits (waitForAcceptCommit and
ad-hoc callers in messages.ts etc.) keep the 1s default so failures
surface fast with the descriptive helper error rather than the generic
Mocha timeout.
2) SessionStore waits still tight
Replaced fixed sleeps with a small `eventually()` poller for the three
"record should be gone after expiry" assertions:
- set of session that expires
- switch from non-expiring to expiring
- get of record from previous run (not yet expired)
These now poll every 25ms up to 2000ms so they pass immediately when
cleanup completes on a fast runner, and tolerate hundreds of ms of
event-loop delay on a slow one. No fixed coupling between sleep
duration and expiry duration.
For the inverse "record should still be there" case in
`shutdown cancels timeouts`, polling doesn't apply (we're verifying
that a cancelled timer did NOT fire, which requires a real wait past
the original expiry). Bumped expires 300→500ms and wait 330→700ms so
setup (set+get+shutdown) has 500ms before the timer would fire (vs.
30ms previously) and the 700ms wait still passes the original expiry.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
dependabot[bot]
|
ce057964a9
|
build(deps-dev): bump lucide-react (#7632)
Bumps the dev-dependencies group with 1 update in the / directory: [lucide-react](https://github.com/lucide-icons/lucide/tree/HEAD/packages/lucide-react). Updates `lucide-react` from 1.11.0 to 1.14.0 - [Release notes](https://github.com/lucide-icons/lucide/releases) - [Commits](https://github.com/lucide-icons/lucide/commits/1.14.0/packages/lucide-react) --- updated-dependencies: - dependency-name: lucide-react dependency-version: 1.14.0 dependency-type: direct:development update-type: version-update:semver-minor dependency-group: dev-dependencies ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
John McLear
|
b8d1c8a192
|
ci(docs): build on PRs and pin Node 22 (Qodo follow-up to #7640) (#7645)
* ci(docs): build on PRs and pin Node 22 (Qodo follow-up to #7640) Qodo flagged two reliability gaps on the oxc-minify fix that landed in #7640: 1. The Deploy Docs to GitHub Pages workflow only ran on push to develop, so a PR that broke `pnpm run docs:build` was not caught until after merge — exactly how the dead-link regression in #7546 escaped. Add a pull_request trigger that runs the same build but skips the deploy/upload steps via `if: github.event_name == 'push'`. Also include the workflow file itself in the path filter so changes to it are exercised on PR. 2. oxc-minify@0.128.0 requires Node ^20.19.0 || >=22.12.0, but the workflow did not pin Node and the repo declared engines.node >=22.0.0 with engineStrict: true — a runner image (or local dev) on Node 22.0–22.11 would refuse to install. Pin Node 22 in the docs workflow with actions/setup-node@v6 (matching the rest of CI), and bump engines.node to >=22.12.0 so the project's engineStrict gate matches the actual minimum. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * ci(docs): split build and deploy so PR runs do not hit pages env protection The previous attempt put `if: github.event_name == 'push'` on individual deploy steps but kept the single job's `environment: github-pages` binding. Environment protection rules reject any non-develop ref (including `refs/pull/N/merge`), so the runner failed the entire job at creation time before any step could execute: Branch "refs/pull/7645/merge" is not allowed to deploy to github-pages due to environment protection rules. Split into two jobs: `build` runs on every trigger (PR + push) and uploads the artifact only on push, `deploy` depends on `build`, runs only on push, and is the only job bound to the github-pages environment. Standard GHA pages-deploy pattern; PR builds never attempt to enter the protected environment. * docs: align Node minimum references with bumped engines.node (Qodo round 2 on #7645) Qodo flagged that engines.node moved from >=22.0.0 to >=22.12.0 in this PR but documentation still claimed the old requirement. Sync the three places that pinned a specific minimum: - README.md installation requirements (>= 22 → >= 22.12) - doc/npm-trusted-publishing.md publish prerequisites (>=22.0.0 → >=22.12.0, with oxc-minify cited as the driver) - CHANGELOG.md 2.7.3 breaking-changes entry (22 → 22.12, with the same oxc-minify justification) --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
d036cf0e70
|
fix(test): null padDeletionToken before pad init to stop modal focus theft (#7643)
PR #7546 added a one-time pad-deletion-token modal that opens via the clientVars handshake on creator sessions and synchronously focuses its input through setTimeout(0). `goToNewPad`'s previous mitigation hid the modal element after `waitForEditorReady`, but the editor iframe attaches before clientVars arrives, so the hide runs against a still- hidden modal, short-circuits, and the modal opens later mid-test — stealing focus and dropping the next Enter / Tab. Visible on develop in `enter.spec.ts:33` and `indentation.spec.ts:9` across all four Playwright jobs (run 25214868650). Intercept `clientVars` assignment via `page.addInitScript` and null out `padDeletionToken` before `pad.ts`'s `showDeletionTokenModalIfPresent` can read it, so the modal-show short-circuits at the source. The deletion-token spec navigates inline with `page.goto` and does not call this helper, so its modal still appears. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
4bda757304
|
feat(api): public compactPad API + bin/compactPad CLI over existing Cleanup (#7567)
* feat(pad): compactHistory() + compactPad CLI for DB-size reclaim Fixes #6194. Long-lived pads with heavy edit history dominate the DB — the issue describes a ~400 MB Postgres after two months with ~100 users. Etherpad keeps every revision forever, and removing arbitrary middle revisions is unsafe because state is reconstructed by composing forward from key revisions. What's safe: collapse the full history into a single base revision that reproduces the current atext. The existing `copyPadWithoutHistory` already does this for a new pad ID — this PR lifts that same changeset pattern into an in-place operation and wires up an admin CLI. - `Pad.compactHistory(authorId?)` (src/node/db/Pad.ts): composes the current atext into one base changeset, deletes all existing rev records, clears saved-revision bookmarks, and appends the new rev 0. Text, attributes, and chat history are preserved; saved-revision pointers are cleared. Returns the number of revisions removed. - `API.compactPad(padID, authorId?)` (src/node/db/API.ts): public-API wrapper around compactHistory. Reports `{removed}` so callers can log savings. - `APIHandler.ts`: register `compactPad` under a new `1.3.1` version, bump `latestApiVersion`. - `bin/compactPad.ts`: admin CLI. Reports the current revision count, calls compactPad via the HTTP API, and prints how many revisions were dropped. - `src/tests/backend/specs/compactPad.ts`: four backend tests cover the empty-pad no-op, the text-preservation + head=0 contract, saved-revision cleanup, and that subsequent edits continue to append cleanly on top of the collapsed base. The operation is destructive so admins must opt in explicitly; the CLI prints the before-count, and the recommended pre-flight is an `.etherpad` export (backup). Closes #6194 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(compact): delegate to copyPadWithoutHistory via temp-pad swap The initial compactHistory() implementation built a custom base changeset and re-ran appendRevision against a reset atext — but the changeset was packed with oldLength=2 (matching copyPadWithoutHistory's dest-pad init state) while the reset atext was only length 1, so applyToText tripped its "mismatched apply: 1 / 2" assertion and every test failed with a Changeset corruption error. Switch to the tested path instead: copy the pad via copyPadWithoutHistory to a uniquely-named temp pad (inherits all its attribute/pool/changeset correctness), read the temp pad's rev records back, delete the old ones under our pad's ID, write the new records in their place, update in-memory state to match, and remove the temp pad. Errors at any step fall through with a best-effort temp-pad cleanup. Contract shifts slightly: the collapsed pad is head<=1 rather than head=0, matching the shape of a freshly-imported pad (seed rev 0 + content rev 1). Tests updated to assert that invariant plus text-preservation, saved-revision cleanup, and append-after-compact. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(6194): match the head<=1 post-compact contract Tests previously asserted head=0 exactly after compaction; the temp-pad-swap path lands at head=1 (one seed rev plus one content rev) matching the shape of a freshly-imported pad. Relax the assertions to and derive the removed-count from before-head minus after-head, so the tests still catch regressions in text-preservation, saved-revision cleanup, and append-after-compact without being tied to the exact implementation shape. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(6194): wrap existing Cleanup instead of duplicating it Develop already ships a working revision-cleanup path under `src/node/utils/Cleanup.ts` with two public helpers — `deleteAllRevisions(padId)` (collapse full history via copyPadWithoutHistory) and `deleteRevisions(padId, keepRevisions)` (keep the last N). The admin-settings UI wires these up but neither is exposed on the public API, and there's no CLI for operators who want to run compaction outside the web UI. That's the gap this PR now fills. Changes from the prior revision of this PR: - Drop `pad.compactHistory()` — it re-implemented what `Cleanup.deleteAllRevisions` already does. Remove the duplicate. - `API.compactPad(padID, keepRevisions?)` now delegates to Cleanup: • keepRevisions null/undefined → deleteAllRevisions (full collapse) • keepRevisions >= 0 → deleteRevisions(N) (keep last N) Returns {ok, mode: 'all' | 'keepLast', keepRevisions?}. - APIHandler `1.3.1`: signature updated to take `keepRevisions` instead of `authorId`. - `bin/compactPad.ts`: accepts `--keep N` for the keep-last mode, shows before/after revision counts so operators see concrete savings. - Backend tests rewritten around the public API surface (mode reporting, text preservation, input validation) rather than internal method plumbing that no longer exists. Net: strictly a thin public-API and CLI veneer over already-tested Cleanup helpers. No new low-level logic. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(6194): assert content markers, not byte-exact atext Cleanup.deleteAllRevisions internally calls copyPadWithoutHistory twice (src → tempId, tempId → src with force=true), and each round trip normalizes trailing whitespace. That meant my byte-exact atext.text assertion failed in CI: expected: '...line 3\n\n\n' actual: '...line 3\n' Swap the comparisons to use content markers (marker-alpha / beta / gamma, keep-line-N). The test still catches the real regressions — if compactPad lost content those markers would disappear — without coupling to whitespace quirks of the existing Cleanup implementation. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(6194): correct API param + document compactPad in http_api docs The 1.3.1 entry in APIHandler registered `['padID', 'authorId']`, but `API.compactPad` takes `(padID, keepRevisions)` and the CLI sends a `keepRevisions` query param. APIHandler.handle dispatches by URL field name, so the previous wiring silently dropped `keepRevisions` and never ran the keep-last branch over HTTP. - Register `['padID', 'keepRevisions']` so the handler forwards the CLI/HTTP arg into the API function. - Add HTTP-level dispatch tests that hit `/api/1.3.1/compactPad` with and without `keepRevisions`. The direct `api.compactPad()` tests bypass the handler and would have missed this regression. - Document compactPad in `doc/api/http_api.md` and `http_api.adoc`, and bump the documented latest version from 1.3.0 to 1.3.1 to match `latestApiVersion`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(6194): add bin/compactAllPads for per-instance bulk compaction `bin/compactPad <padID>` covers the case where you know which pad is fat. For "reclaim space across the whole instance," composing `listAllPads` + `compactPad` yourself is annoying; this script does it. - Walks every pad on the instance and compacts it (full collapse, or `--keep N` keep-last). - Per-pad failures don't abort the run — they're logged, counted, and the script exits 1 if any failed. - `--dry-run` lists pads + revision counts without writing anything, so operators can scope impact before committing. - Reports `before → after` per pad and a total reclaimed count. Deliberately not adding a `compactAllPads` HTTP API: bulk compaction over a single HTTP request means one giant response and a long-held connection. Operators who want this should run it locally, where they can see progress and kill it cleanly. Staleness gating ("only pads older than X days") is tracked separately as a follow-up. Also registers `compactPad` and `compactAllPads` script aliases in `bin/package.json` so they show up next to the other admin CLIs. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(6194): cover the bin/compactAllPads loop logic Previous commit added the script but only exercised it by hand. The loop itself — error tolerance, dry-run gating, keep-last passthrough, the empty-instance and listAllPads-failure paths — had no automated coverage. - Refactor compactAllPads.ts to export `runCompactAll(api, opts, logger)` and `parseArgs(argv)`. The CLI shell wires them up to axios+APIKEY for production; tests use an in-memory `CompactAllApi` so we don't need to stand up the apikey-auth path in mocha. - Add 9 specs covering: arg parsing, full-collapse iteration, --keep N passthrough, --dry-run skipping writes, single-pad failure not aborting the run, pre-flight count failure tolerated, a listAllPads failure short-circuiting cleanly, the empty-instance no-op, and a final end-to-end test that runs `runCompactAll` against the real `/api/1.3.1/compactPad` handler over supertest+JWT to catch contract drift between the CompactAllApi shape and the HTTP endpoints. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(6194): address Qodo review — gate, integer check, SSL Three valid concerns from the Qodo review on 75a08a13: 1. **cleanup.enabled gate.** The admin/Cleanup-socket path checks `settings.cleanup.enabled` before doing anything destructive; the public API was bypassing that gate. Now `compactPad` mirrors the admin path's check and returns a clear apierror when disabled, so exposing the API doesn't accidentally widen the cleanup-opt-in surface. 2. **Number.isFinite → Number.isInteger.** `2.5` was finite and non-negative, so the old check let it through into `Cleanup.deleteRevisions`, which does revision-index arithmetic that assumes integer math. Reject at the API boundary instead of silently misbehaving. 3. **SSL-aware baseURL in the bin scripts.** Other bin scripts hardcode `http://`, but the rest of the codebase uses `settings.ssl ? 'https' : 'http'`. The compact CLIs now do the same, so they work against HTTPS deployments. (Other bin scripts carry the same bug but fixing them is out of scope for this PR.) Tests: - New spec: `rejects fractional keepRevisions` (2.5 with the old check passed; the new one rejects). - New spec: `refuses to run when cleanup.enabled is false`. The existing API tests opt in via a before-hook + restore, so they still cover the success path under the new gate. - API docs (`http_api.md` + `http_api.adoc`) document the gate and the new error message. Skipped Qodo concerns: - "Wrong compactPad parameters" — already fixed in 26e12ff7 (the param map now correctly says `keepRevisions`, not `authorId`). - "Unbounded revision deletions" / "No session eviction" / changeset base-length / padCreate hook — these all targeted the earlier on-Pad implementation that was refactored away. The current code wraps `Cleanup.deleteAllRevisions` / `deleteRevisions`, which already handle concurrency, locking, and hook semantics. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
b47fcd819b
|
fix(docs): replace dead privacy.md link with GitHub URL (#7641)
PR #7546 added a relative link in `doc/privacy.md` pointing to `../docs/superpowers/specs/2026-04-18-gdpr-pr1-deletion-controls-design.md`, which lives outside vitepress's `doc/` source root. VitePress reports it as a dead link and the docs deploy on develop fails: (!) Found dead link ./../docs/superpowers/specs/2026-04-18-gdpr-pr1-deletion-controls-design in file /home/runner/work/etherpad/etherpad/doc/privacy.md Error: 1 dead link(s) found. Point the link at the file on GitHub instead so the published site resolves it and readers can still find the spec. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
5e8704f8d8
|
feat(gdpr): pad deletion controls (PR1 of #6701) (#7546)
* docs: PR1 GDPR deletion-controls design spec First of five GDPR PRs tracked in #6701. PR1 covers deletion controls: one-time deletion token, allowPadDeletionByAllUsers flag, authorisation matrix for handlePadDelete and the REST deletePad endpoint, a single token-display modal for browser pad creators, and test coverage. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs: PR1 GDPR deletion-controls implementation plan 13 TDD-structured tasks covering PadDeletionManager unit tests, socket + REST three-way auth, clientVars wiring, one-time token modal, delete-with-token UI, Playwright coverage, and PR handoff. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(gdpr): scaffolding for pad deletion tokens PadDeletionManager stores a sha256-hashed per-pad deletion token and verifies it with timing-safe comparison. createPad / createGroupPad return the plaintext token once on first creation, and Pad.remove() cleans it up. Gated behind the new allowPadDeletionByAllUsers flag which defaults to false to preserve existing behaviour. Part of #6701 (GDPR PR1). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix+test(gdpr): lazy DB access in PadDeletionManager + unit tests Capturing DB.db at module-load time was null until DB.init() ran, which broke importing the module outside a live server (including from the test runner). Switch to DB.db.* at call time and add unit tests exercising create/verify/remove plus timing-safe comparison. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(gdpr): three-way auth for socket PAD_DELETE Creator cookie → valid deletion token → allowPadDeletionByAllUsers flag. Anyone else still gets the existing refusal shout. * feat(gdpr): optional deletionToken on programmatic deletePad * feat(gdpr): advertise optional deletionToken on REST deletePad * test(gdpr): cover deletePad authorisation matrix via REST * feat(gdpr): surface padDeletionToken in clientVars for creators only Revision-0 author on their first CLIENT_READY visit receives the plaintext token; all subsequent CLIENT_READYs receive null because createDeletionTokenIfAbsent is idempotent. Readonly sessions and any other user never see the token. * i18n(gdpr): strings for deletion-token modal and delete-with-token flow * feat(gdpr): token modal + delete-with-token disclosure markup * feat(gdpr): show deletion token once, allow delete via recovery token * style(gdpr): modal + delete-with-token layout * test(gdpr): Playwright coverage for deletion-token modal + delete-with-token * fix(test): auto-dismiss deletion-token modal in goToNewPad helper The token modal introduced in PR1 blocks clicks for every Playwright test that creates a new pad via the shared helper. Add a one-line dismissal so unrelated tests keep passing, and have the deletion-token spec navigate inline via newPadKeepingModal() when it needs the modal open to capture the token. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(test): dismiss deletion-token modal without focus transfer Clicking the ack button transferred focus out of the pad iframe, which made subsequent keyboard-driven tests (Tab / Enter) silently miss the editor. Swap the click for a page.evaluate() that hides the modal and nulls clientVars.padDeletionToken directly, leaving focus where it was. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(gdpr): PadDeletionManager race + document createPad/deletePad Qodo review: - createDeletionTokenIfAbsent() was a non-atomic read-then-write. Two concurrent callers for the same pad could both return different plaintext tokens while only the later hash was stored, leaving the first caller with an unusable recovery token. Serialise per-pad via a Promise chain and add a regression test that fires 8 concurrent calls and asserts exactly one plaintext is emitted and validates. - doc/api/http_api.md now documents createPad returning deletionToken and deletePad accepting the optional deletionToken parameter. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(gdpr): always render delete-with-token in settings popup The rebase onto develop placed the delete-pad-with-token details inside the pad-settings-section conditional, which is only rendered when enablePadWideSettings is true AND the section is toggled visible. Second-device recovery (typing the captured token on a fresh browser) must work without pad-wide settings enabled, so move the details out to sit alongside the existing pad_deletion_token.spec.ts expectations. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(gdpr): require valid token when supplied, gate on auth, harden a11y/i18n - PadMessageHandler: a supplied deletion token must validate; do not fall back to the creator-cookie path when the token is wrong (was deleting the pad anyway when the creator pasted a wrong token into the field). - Skip token issuance + UI when requireAuthentication is on (creator identity is stable, recovery token is redundant noise). - Server emits messageKey instead of hardcoded English; both shout handlers (inline alert and global gritter) localize via html10n. - Suppress the global "Admin message" gritter for pad.deletionToken.* shouts to avoid the "Admin message: undefined" duplicate. - Token-modal a11y: role=dialog, aria-modal, aria-labelledby/describedby, visually-hidden label on the token input, aria-live on Copy, focus to the token input on open and restore on dismiss. - Style the "Delete Pad with Token" disclosure to match the Delete pad button; align the Copy/value row; pad the disclosure label. Tests: Playwright now covers the creator-with-wrong-token path, asserts no "Admin message" / "undefined" gritter on denial; backend API test covers requireAuthentication suppressing the token. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
7357871acd
|
fix(docs): add oxc-minify so vitepress builds with rolldown-vite (#7640)
VitePress 2.0 alpha refuses to build when the `vite` override resolves
to rolldown-vite unless `oxc-minify` is installed, which broke the
"Deploy Docs to GitHub Pages" workflow on develop:
`oxc-minify` is not installed. vitepress requires `oxc-minify`
to be installed when rolldown-vite is used.
Add it as a dev dependency of the doc workspace.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
John McLear
|
6195289198
|
feat(gdpr): IP/privacy audit (PR2 of #6701) (#7547)
* docs: PR2 GDPR IP/privacy audit design spec Second of five GDPR PRs (#6701). Audit identifies four log-sites that leak IPs despite disableIPlogging=true, proposes a tri-state ipLogging setting with a back-compat shim, and specifies a doc/privacy.md that documents Etherpad's actual IP handling. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs: PR2 GDPR IP/privacy audit implementation plan 7 TDD-structured tasks: anonymizeIp helper + unit tests, tri-state ipLogging setting with disableIPlogging deprecation shim, wiring through 5 leaking log sites, clientVars.clientIp removal, access-log integration test, doc/privacy.md, and PR handoff. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(gdpr): anonymizeIp helper with v4/v6/v4-mapped truncation * feat(gdpr): tri-state ipLogging setting + disableIPlogging shim * fix(gdpr): route every IP log site through anonymizeIp Closes four leaks where disableIPlogging was silently ignored (rate-limit warn, both auth-log calls in webaccess, import/export rate-limit warn) and normalises the four that did honour the flag onto the new ipLogging tri-state via the shared helper. * chore(gdpr): drop dead clientVars.clientIp placeholder Server side: remove the literal '127.0.0.1' assignments from both clientVars and collab_client_vars. Type side: drop clientIp from ClientVarPayload and ServerVar. pad.getClientIp now returns the same '127.0.0.1' literal as a plugin-compat shim (pad_utils.uniqueId still uses it as a prefix). * test(gdpr): ipLogging modes + disableIPlogging shim * docs(gdpr): operator-facing privacy and IP handling statement * fix(gdpr): validate ipLogging at load + regression test for log sites Qodo review: - settings.ipLogging is loaded as a trusted union but nothing enforced the shape. An unknown value (e.g. a typo or null) silently fell through to anonymizeIp's "truncated" branch and emitted partially redacted IPs. Fall back to "anonymous" with a WARN at load time. - New regression test scans the four known log-sites for raw req.ip / socket.request.ip / request.ip inside logger calls that don't wrap through anonymizeIp / logIp, so a future edit that re-introduces a raw IP fails CI. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
e39dbde887
|
feat(updater): tier 1 — notify admin and pad users of available updates (#7601)
* docs(updater): add four-tier auto-update design spec
Four-tier opt-in self-update subsystem (off / notify / manual / auto / autonomous).
GitHub Releases as source of truth; install-method auto-detection with admin
override; in-process execution with supervisor restart; 60s drain + announce;
auto-rollback on health-check failure with crash-loop guard. Pad-side severe/
vulnerable badge that does not leak the running version. Top-level adminEmail
with escalating cadence (weekly while vulnerable, monthly while severe).
Refs: docs/superpowers/specs/2026-04-25-auto-update-design.md
* docs(updater): add PR 1 (Tier 1 notify) implementation plan
Bite-sized TDD task breakdown for shipping Tier 1 notify only:
- VersionChecker, InstallMethodDetector, UpdatePolicy, Notifier, state modules
- /admin/update/status (admin-auth) and /api/version-status (public, no version leak)
- Admin UI banner + read-only update page + nav link
- Pad-side severe/vulnerable footer badge
- Settings: updates.* block + top-level adminEmail
- Tests: vitest unit + mocha integration + Playwright admin/pad
- CHANGELOG + doc/admin/updates.md
PRs 2-4 (manual/auto/autonomous) get their own plans after PR 1 lands.
* feat(updater): add shared types for auto-update subsystem
* feat(updater): clarify OutdatedLevel and EMPTY_STATE doc, drop path header
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* feat(updater): add semver helpers and vulnerable-below parser
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix(updater): tighten semver regex to reject four-part versions
* feat(updater): add state persistence with schema validation
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix(updater): reject null email and array latest in state validation
typeof null === 'object' meant {email:null} passed the old isValid check,
which would crash downstream Notifier code reading email.severeAt. Likewise,
an array would pass the typeof latest === 'object' branch. Introduce
isPlainObject helper (null-safe, Array.isArray guard) and use it for both
fields. Adds two regression tests covering the exact broken inputs.
* feat(updater): add install-method detector with override
* feat(updater): add policy evaluator
* feat(updater): add GitHub Releases checker with ETag support
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix(updater): validate release fields and preserve ETag on prerelease
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* feat(updater): add email cadence decider
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix(updater): tagChanged email fires regardless of cadence; drop unused field
* feat(settings): add updates.* and adminEmail settings
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* feat(updater): wire boot hook and periodic checker
Register expressCreateServer/shutdown hooks in ep.json and implement
the boot-wiring module that detects install method, starts the polling
interval and runs the notifier dedupe pass each tick.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* feat(updater): add /admin/update/status and /api/version-status endpoints
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* i18n(updater): add english strings for update banner, page, and pad badge
* feat(updater): add pad footer badge for severe/vulnerable status
* feat(admin-ui): add update banner, page, and nav link
Add UpdateStatusPayload to the zustand store, a persistent UpdateBanner
rendered in the App layout, a /update page showing version details and
changelog, and a Bell nav link — all wired to the /admin/update/status
endpoint added in Task 10.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* test(updater): add Playwright specs for admin banner/page and pad badge
* docs(updater): document tier 1 settings, badge, email cadence
* refactor(updater): dedupe helpers, fix misleading log, add banner styling
- Export stateFilePath from index.ts and import it in updateStatus.ts (removes local duplicate)
- Import getEpVersion from Settings.ts in both index.ts and updateStatus.ts (removes two local definitions)
- Fix misleading 'backing off' log message — no backoff is implemented, just retries at next interval
- Remove EMPTY_STATE_FOR_TESTS re-export from state.ts; state.test.ts now imports EMPTY_STATE directly from types.ts
- Add .update-banner and .update-page CSS rules to admin/src/index.css
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* fix(updater): address review feedback — async wrap, tier=off skip, poll race, opt-in admin gate
- Wrap /api/version-status and /admin/update/status with a small async helper
so a rejected promise becomes next(err) instead of an unhandled rejection.
- Short-circuit route registration when updates.tier === 'off' so the heavier
opt-out also removes the HTTP surface (matches pre-PR behavior for that case).
- Add an in-flight guard around performCheck() so overlapping interval ticks
can't race on update-state.json writes or duplicate email decisions; track
the initial setTimeout handle and clear it in shutdown().
- Add updates.requireAdminForStatus (default false) so admins can lock
/admin/update/status to authenticated admin sessions without disabling the
updater. Default false preserves current behavior (the running version is
already exposed publicly via /health). Backend specs cover unauth → 401,
non-admin → 403, admin → 200.
- Bump admin troubleshooting menu count test 5 → 6 to account for the new
Update nav link.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(updater): address Qodo round-2 review feedback
Round 2 of Qodo review on #7601. Addressing the action-required items:
#1 Badge bypassed pad baseURL — derive basePath the same way
padBootstrap.js does (`new URL('..', window.location.href).pathname`)
and prefix the fetch with it. Subpath deployments now reach
/<prefix>/api/version-status instead of 404ing.
#2 Updater poller could get stuck — `getCurrentState()` is now inside
the try/finally so a one-time loadState() rejection can't leave
`checkInFlight=true` and permanently silence polling.
#3 Updates off hung admin page — UpdatePage now self-fetches and
renders explicit `disabled` (404), `unauthorized` (401/403), and
`error` states instead of staying on "Loading...". Banner-driven
prefetch is still honoured if it landed first.
#11 NaN polling interval — coerce `checkIntervalHours` to a number,
clamp to [1h, 168h], log a warning and fall back to 6h on
non-finite input. Math.max(1, NaN) === NaN previously meant a
malformed settings.json could turn the poller into a tight loop.
#13 State validation accepted broken subfields — `isValid()` now
inspects `latest.{version,tag,body,publishedAt,htmlUrl,prerelease}`,
`vulnerableBelow[].{announcedBy,threshold}`, and
`email.{severeAt,vulnerableAt,vulnerableNewReleaseTag}`. A
hand-edited file with a number where a string is expected is now
treated as corrupt and reset to EMPTY_STATE rather than crashing
later in semver parsing or email rendering.
#14 Badge cache stampede — wrap `computeOutdated()` in a single-flight
promise so concurrent requests at cache expiry await one shared
computation instead of fanning out into N redundant disk reads.
Plus six new state.test.ts cases covering each new validation guard.
Pushing back on the remaining items:
#4 `updates.tier` defaults to `notify` — intentional. The whole point
of tier 1 is to surface the "you are behind" signal to admins by
default. Opt-in defeats the purpose; the existing failure mode
(admin never hears about a security-relevant release) is exactly
what this PR is fixing.
#5/#8 Admin status endpoint admin-auth — `currentVersion` is already
public via `/health`, so wrapping the route in admin-auth doesn't
reduce the disclosure surface meaningfully. Operators who want it
gated set `updates.requireAdminForStatus=true` (already wired and
covered by the comment on the route handler).
#10 Plain `https://` URLs in planning doc — planning markdown is
viewed in editors and on GitHub where protocol-relative URLs would
either render literally or break entirely. Keeping `https://`.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
|
||
|
John McLear
|
85f9a5f2f5
|
feat: Open Graph & Twitter Card metadata for pad/timeslider/home (closes #7599) (#7635)
* docs(spec): Open Graph metadata for pad pages (issue #7599) Spec for adding og:* and twitter:card meta tags to /p/:pad, the timeslider, and the homepage so shared links unfurl with a useful preview in chat apps. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(spec): expand OG spec — i18n (locale map + og:locale) and a11y (image:alt) Address review feedback: socialDescription accepts a per-language map, og:locale is emitted from the negotiated render language, and image:alt attributes are emitted for screen readers in chat clients. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat: emit Open Graph & Twitter Card metadata for pad/timeslider/home Closes #7599. Pad URLs shared in chat apps (WhatsApp, Signal, Slack, etc.) previously unfurled with no preview because the rendered HTML carried no OG or Twitter Card metadata. This change emits og:title, og:description, og:image, og:url, og:site_name, og:type, og:locale, og:image:alt and the equivalent twitter:* tags on the pad page, the timeslider, and the homepage. A new settings.json key `socialDescription` controls the description. It accepts either a plain string applied to every locale or a per-language map keyed by BCP-47 tag with an optional `default` fallback. og:locale is emitted from the language already negotiated via req.acceptsLanguages and og:image:alt provides screen-reader text for chat-client previews. Pad names from the URL are HTML-escaped before being interpolated into og:title to prevent reflected XSS via crafted pad IDs. Tests: src/tests/backend/specs/socialMeta.ts covers the default, per-locale override, locale fallback, URL decoding, XSS escape, and the timeslider/homepage variants. Semver: minor (new setting; templates emit additional tags but no existing behavior changes). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(test): use valid pad-name char in URL-decode test Spaces aren't allowed in pad names — Etherpad redirected /p/Has%20Space* to a sanitized name (302), so the og:title assertion failed. Use %2D ("-") instead, which is a valid pad-name character and still exercises the URL-decode path. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(socialMeta): don't double-decode pad name from req.params.pad Express has already URL-decoded :pad route params before they reach the handler. Calling decodeURIComponent on the result throws URIError for pad names containing a literal "%" — e.g. the URL /p/100%25 yields req.params.pad === "100%", and decodeURIComponent("100%") throws. This would have prevented the page from rendering for some valid pad IDs. Drop the redundant decode and add a regression test for the "%" case. Reported by Qodo on PR #7635. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(socialMeta): source description from i18n catalog, drop settings key Per review: the OG description is a translatable string and belongs in Etherpad's locale files alongside the rest of the UI strings, not in settings.json. Operators who want to override it per-language continue to use the standard customLocaleStrings mechanism — no new config surface. Changes: - Add "pad.social.description" to src/locales/en.json (default English). - Export i18n.locales so server-side renderers can look up translations. - socialMeta.renderSocialMeta now takes a `locales` map and resolves renderLang → primary subtag → en, instead of taking a per-locale map from settings. - Remove `socialDescription` from Settings.ts, settings.json.template, settings.json.docker (the key never shipped). - Update tests and spec doc to reflect i18n-sourced description. Reported by Qodo on PR #7635 (also confirmed feature is fine to land default-on; no flag needed). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(socialMeta): add unit tests for pure helpers 21 cases exercising buildSocialMetaHtml and renderSocialMeta directly, without HTTP/DB. Covers tag enumeration, HTML escaping, og:locale region formatting, title composition (pad/timeslider/home), description i18n resolution (exact/primary/en fallback, missing catalog), image URL (default favicon vs absolute settings.favicon vs alt text), canonical URL building with query-string stripping, the literal "%" no-throw regression, and attribute-breakout escape. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(socialMeta): defend og:url/og:image against host-header poisoning Previously og:url and og:image were built from req.protocol + req.get('host'), both of which can be client-controlled (Host header directly, or X-Forwarded-* under trust proxy). A crafted Host could make the server emit OG tags pointing at an attacker's origin — harmful if any cache fronts the response or if a vulnerable proxy forwards the headers unsanitized. Two-layer defense: 1. New optional setting `publicURL` lets operators pin the canonical origin used for shared link previews ("https://pad.example"). When set, og:url and og:image use it unconditionally. Sanitized at use time: must be http(s)://host[:port] with no path, no userinfo, no trailing slash; malformed values fall back to the request. 2. When `publicURL` is unset, the request-derived fallback now strictly validates the Host header against /^[a-z0-9]([a-z0-9.-]{0,253}[a-z0-9])?(:\d{1,5})?$/i and caps the scheme to "http"/"https". A crafted Host (CRLF injection, userinfo, "<script>") is replaced with "localhost" instead of being echoed into og:url. Reported by Qodo on PR #7635. Tests: 5 new unit cases covering publicURL preference, trailing-slash strip, malformed-publicURL fallback, Host validation, scheme cap. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(socialMeta): tighten types, drop `any` - `req: any` -> express `Request` (covers acceptsLanguages/protocol/get/originalUrl). - `settings: any` -> local `SocialMetaSettings` interface narrowed to the three fields we actually read (title/favicon/publicURL); avoids coupling to the full Settings module surface. - `availableLangs: {[k: string]: any}` -> `{[lang: string]: unknown}`; only keys are read, so values stay deliberately unconstrained. No runtime change. All 26 socialMeta unit tests still pass. Per Sam's review on #7635. --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
63cae17720
|
feat(pad): add theme-color meta to match toolbar on mobile (#7606) (#7636)
* feat(pad): add <meta name="theme-color"> matching toolbar (#7606) Mobile browsers paint the address-bar / status-bar area above the viewport. Without theme-color this is a system color that does not match the Etherpad toolbar, leaving a visible gap above the pad. Render <meta name="theme-color"> server-side so the bar matches the configured toolbar on first paint. Light + dark variants are emitted with prefers-color-scheme media queries when dark mode is enabled. Colors are derived from settings.skinVariants via a new SkinColors helper (mirrors --bg-color in the colibris pad-variants.css). Closes #7606 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(timeslider): emit single theme-color matching configured toolbar Qodo flagged a mismatch: timeslider does not switch skin variants on prefers-color-scheme, so emitting a dark theme-color via media query would leave dark-mode devices with a dark address bar over a light toolbar. Drop the media-query metas on timeslider and emit one unconditional theme-color resolved from settings.skinVariants. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(pad): emit unconditional theme-color so dark-OS users still match Qodo flagged that gating the light theme-color on prefers-color-scheme: light leaves no applicable meta on dark-OS devices when enableDarkMode is false — the address bar then uses a system color while the toolbar stays light. Drop the light media query so the light theme-color is the baseline, and let the prefers-color-scheme: dark meta override it when dark mode is enabled. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(theme-color): align dark meta with client-side super-dark override Two related Qodo findings on the SkinColors helper: - The pad client's dark-mode auto-switch (pad.ts L650) forces super-dark-toolbar regardless of the configured skinVariants, so the prefers-color-scheme: dark meta must always be #485365 — not whichever dark variant the operator configured. - When skinVariants only carries a dark token (e.g. dark-toolbar), the previous helper left the baseline meta at #ffffff, so light-OS users would see white above a dark toolbar. Replace toolbarThemeColors() with configuredToolbarColor() (used as the unconditional baseline) and a fixed DARK_MODE_TOOLBAR_COLOR constant (used in the prefers-color-scheme: dark meta). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(theme-color): server-side only, drop fragile dark media query Address remaining Qodo findings on the theme-color rollout: - (#1) Skip emitting the meta entirely when settings.skinName is not colibris — the helper only knows colibris's --bg-color values, so on no-skin or third-party skins the previous code would emit a white meta over a non-white toolbar. - (#4) Drop the prefers-color-scheme: dark variant. The pad's client-side dark mode is also gated on a localStorage white-mode override that no media query can express, so the dark meta could paint a dark address bar over a still-light toolbar. The single baseline meta always matches what the user sees on first paint. - (#8) Remove the redundant module.exports assignment; rely on the ES named export only (tsx handles the require() interop). - (#9) Iterate the toolbar variants in CSS source order and let the last match win, matching the cascade in pad-variants.css when multiple *-toolbar tokens are present. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
4704d80e82
|
ci: test ep_font_color and ep_hash_auth in with-plugins matrix (#7639)
* ci: add ep_font_color and ep_hash_auth to plugin test matrix These are the #12 and #14 most-installed Etherpad plugins on npm (last 30d) and were the only top-15 plugins not exercised by the withpluginsLinux / withpluginsWindows / Playwright with-plugins jobs. Adding them broadens coverage of the plugin loader against two real-world hooks: aceEditorCSS / aceAttribsToClasses (ep_font_color) and authenticate / handleMessage (ep_hash_auth). ep_hash_auth's authenticate hook is a no-op unless a Basic auth header is sent and a matching settings.users[user].hash exists, so it falls through cleanly with the default test settings. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(change_user_color): close users popup before opening chat The "Own user color is shown when you enter a chat" spec leaves the users popup open after picking a color, then calls showChat(). In the with-plugins matrix the popup overlaps #chaticon and intercepts pointer events, so the click in showChat() is retried until the 90s timeout (× 5 retries ≈ 7m), failing both Firefox and Chrome with-plugins jobs. Toggle the users button off and wait for popup-show to drop before clicking the chat icon, matching the close pattern used in a11y_dialogs.spec.ts. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
dependabot[bot]
|
1bbdc8fb9b
|
build(deps): bump jsdom from 29.1.0 to 29.1.1 (#7637)
Bumps [jsdom](https://github.com/jsdom/jsdom) from 29.1.0 to 29.1.1. - [Release notes](https://github.com/jsdom/jsdom/releases) - [Commits](https://github.com/jsdom/jsdom/compare/v29.1.0...v29.1.1) --- updated-dependencies: - dependency-name: jsdom dependency-version: 29.1.1 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
translatewiki.net
|
60f252916c
|
Localisation updates from https://translatewiki.net. | ||
|
John McLear
|
b8a950ee92
|
fix: delay anchor line scrolling until layout settles (#7544)
* fix: delay anchor line scrolling until layout settles Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * fix: anchor reapply loop cancels on user interaction Addresses Qodo review: the 10s reapply loop could fight the user when they tried to scroll or click away from the anchored line. Listen for wheel/touchmove/keydown/mousedown on both ace_outer and ace_inner documents in capture phase and tear down the interval on first signal. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix: anchor reapply loop exits early once layout settles + FF rationale Addresses Qodo review on #7544: 1. Requirement gap (#1): Add stability detection to focusOnLine()'s reapply loop. When the target line's offsetTop has not changed for 3 consecutive 250ms ticks (~750ms), stop() is called early instead of running the full 10s window. This means once late content is no longer shifting layout, the loop releases the user immediately rather than waiting out maxSettleDuration. 2. Maintainability (#4): Add a comment explaining why the previous $.animate({scrollTop}) "needed for FF" path was replaced with a direct .scrollTop() call — the settle interval now covers the late-layout case Firefox originally needed animation for. Also adds a test that the reapply loop exits early so a user-initiated scrollTop=0 after ~2s is not reverted by another reapply tick. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(anchor-scroll): tolerance, min-settle window, missing-anchor bail-out Round 3 of Qodo review on #7544: #3 Early exit misses late shifts — image loads / plugin renders past my previous 750ms early-exit window were no longer corrected. Add a `minSettleDuration` of 2s before any early-exit can fire, and bump `stableTicksRequired` from 3 to 4. Hard ceiling stays 10s. #4 Offset equality prevents stability — strict === on `offset().top` never matched in the presence of sub-pixel rounding, so the loop ran the full 10s even on stable layouts. Switch to `Math.abs(...) < 1` tolerance. #7 Invalid anchors spin interval — when `getCurrentTargetOffset()` keeps returning null (the requested line never resolves), the loop used to run for the full 10s doing nothing. Track consecutive misses and `stop()` after `missingTicksRequired` (8 ticks ≈ 2s). Real "inner doc not yet rendered" cases get the first 2s window. Bump the early-exit test's wait from 2s → 3.5s to clear the new `minSettleDuration` + `stableTicksRequired` window before asserting. Pushing back on remaining Qodo items: #1 Defer scroll until layout settles — the design is "scroll once immediately so the user sees the line, then keep correcting". Deferring all scrolling until "stable" (which is unknowable up front) would visibly hang on `#L...` navigation for seconds while nothing happens. The reapply loop is the deferral. #6 FF rationale lost — already addressed in the previous commit (comment on the `scrollTop()` call explaining why the `$.animate({scrollTop})` "needed for FF" path was removed). Qodo's persistent review doesn't track resolution of items that aren't touched by the new commit. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
cafd60aa21
|
test(playwright): un-skip ep_headings2 spec under WITH_PLUGINS (#7634)
Remove the FRONTEND_IGNORE entry that suppressed ep_headings2/static/tests/frontend-new/specs/headings.spec.ts under WITH_PLUGINS=1. The skip was added in #7628 while the keystroke-drop flake (#7611) was still being chased; #7630 then identified the actual root cause as ep_cursortrace's per-keystroke cursorPosition socket spam saturating Firefox's input pipeline, removed ep_cursortrace from the WITH_PLUGINS plugin set, and added waitForEditorReady() to goToNewPad/goToPad. With both root causes addressed, this skip is likely stale — the spec's own "Option select is changed when heading is changed" test already uses insertText for the second-line typing, so it should clear the same bar that #7630 cleared for ep_markdown and ep_spellcheck (both now passing on develop). Closes ether/etherpad#7626 if CI confirms — the issue's three plugin specs (markdown, spellcheck, headings2) and timeslider_identity_changeset are all addressed once this lands. If headings2 is still flaky after this, FRONTEND_IGNORE comes back with a narrower comment about what specifically still races. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
bbd29683d9
|
ci(frontend-tests): exclude ep_cursortrace + un-flake 30 of 31 #7611 skips (#7630)
* test(playwright): wait for editor editability in goToNewPad/goToPad #editorcontainer.initialized fires after padeditor.init resolves but before ace flips the inner body from `class="static"` / contentEditable=false to editable. Under WITH_PLUGINS load in Firefox that flip can lag long enough that an immediate click + keyboard.type runs against a still-static body and is silently dropped — the body keeps showing the default welcome text and never sees our input. Most of the specs that currently carry `test.skip(WITH_PLUGINS)` markers (#7611) are racing exactly this flip. Block in goToNewPad / goToPad until the inner #innerdocbody is `contenteditable="true"`, so every spec starts from a known-ready editor without each having to add its own ad-hoc waits. Value-driven: exits as soon as ace flips the attribute, no fixed delay. Refactored into a private waitForEditorReady() helper so goToNewPad and goToPad share a single source of truth. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): un-skip bold.spec under WITH_PLUGINS The two skipped tests fail because clicking the bold toolbar button right after selectAllText is intercepted by the #toolbar-overlay div (same root cause that needed force:true in clearAuthorship and ep_align). Add force:true to the click and drop the test.skip(WITH_PLUGINS) markers. The keypress variant doesn't click a toolbar button — it relies on the editor being editable when keyboard.press fires. The previous commit (waitForEditorReady in goToNewPad) covers that. Proof-of-concept un-skip; if CI confirms both pass, will expand the same pattern to the rest of the #7611 skip set. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): make bold.spec robust to Firefox + WITH_PLUGINS The previous attempt at un-skipping these tests added force:true on the toolbar click but left the legacy selectAllText + keyboard.type sequence in place. Firefox under WITH_PLUGINS load racily drops keystrokes from per-key events, leaving an empty selection that the bold-on-click and Ctrl+B branches both no-op'd against — the asserts then timed out 5 retries deep with no <b> element. Replace the selectAllText + keyboard.type prelude with the standard clearPadContent + writeToPad pair. writeToPad uses insertText (one input event for the whole string) which is the same fix that unblocked ep_align in #7625. Verified locally on Firefox + WITH_PLUGINS=1: 2/2 pass in 15s. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): un-skip 4 writeToPad-only specs under WITH_PLUGINS These four specs were marked test.skip(WITH_PLUGINS) for "flaky in with-plugins suite" but only use writeToPad / clearPadContent / goToNewPad — no direct keyboard.type, no toolbar button clicks. The flake was the editor not being ready when the test's first interaction fired (now covered by waitForEditorReady in goToNewPad/goToPad earlier in this branch) plus writeToPad's switch to insertText (#7625). - urls_become_clickable.spec.ts (file-level skip) - unaccepted_commit_warning.spec.ts - undo_clear_authorship.spec.ts - timeslider_follow.spec.ts Just removing the skip lines is enough; no other changes needed. Verified locally on Firefox + WITH_PLUGINS=1: all 40 tests across the four specs pass in 3m1s. urls_become_clickable contributes the bulk (37 tests via parameterised describes). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): un-skip page_up_down and timeslider_line_numbers under WITH_PLUGINS Both specs use writeToPad + keyboard.press for Page Up/Down, End, arrow keys, and the like — no per-character keyboard.type, no toolbar button clicks. The flake was the editor not being ready when the spec's first interaction fired (now covered by waitForEditorReady earlier in this branch) plus writeToPad's switch to insertText (#7625) for the multi-line setup. - page_up_down.spec.ts (3 skips) - timeslider_line_numbers.spec.ts (1 skip) Verified locally on Firefox + WITH_PLUGINS=1: 5/5 tests pass. enter.spec.ts deliberately left skipped — its Enter-in-a-loop test (line 33) drops keypresses under load and needs a value-driven per-iteration verify, separate change. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): un-skip chat/list_wrap/clear_authorship; re-skip undo_clear_authorship Three more files cleared after the editor-ready helper landed: - chat.spec.ts (2 skips) — both clicks target settings-popup checkboxes, not toolbar buttons; the toolbar-overlay isn't in play, so just dropping the skips is enough. - clear_authorship_color.spec.ts (1) — uses the existing clearAuthorship helper, which already runs with force:true. - list_wrap_indent.spec.ts (1) — adds force:true to the .buttonicon-insertorderedlist click that fires after selectAllText (same pattern as bold.spec). Reverts the un-skip on undo_clear_authorship.spec.ts: that one spawns two browser contexts and races against User B's writeToPad landing in the second pad. Hit a real flake locally where User B's text never appeared. Needs a per-user "wait for text to commit" before the assertion. Re-add the skip until that fix is in. Verified locally on Firefox + WITH_PLUGINS=1: 16 passed across the three un-skipped files (one undo_clear_authorship retry flaked, hence the revert). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): un-skip alphabet/delete/select_focus_restore under WITH_PLUGINS - alphabet.spec.ts (1) — swapped page.keyboard.type for writeToPad - delete.spec.ts (1) — same swap - select_focus_restore.spec.ts (1) — left keyboard.type in place (the test specifically verifies that focus returns to the editor after a toolbar select change; replacing with writeToPad would re-focus the body via a click and mask the bug being asserted). Editor-ready wait alone is enough here. Verified locally on Firefox + WITH_PLUGINS=1: 3/3 pass in 23s. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): un-skip bold_paste + undo_redo_scroll under WITH_PLUGINS - bold_paste.spec.ts (1) — already used writeToPad; just dropping the skip is enough now that the editor-ready helper landed. - undo_redo_scroll.spec.ts (2) — replaced the `for (45 lines) { keyboard.type; keyboard.press('Enter') }` loop with a single writeToPad of `lines.join('\\n') + '\\n'`. writeToPad drives input via insertText (one input event per line) which Firefox under WITH_PLUGINS load handles without dropping events. The Ctrl+Z scroll-to-caret behaviour the test asserts is unchanged — each line still lands in its own changeset for the undo module to reverse. Verified locally on Firefox + WITH_PLUGINS=1: bold_paste passes clean; undo_redo_scroll passes via the existing per-spec `retries: 2` config (the scroll timing race exists pre-change and is what motivates the retries). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): un-skip unordered_list 'enter for the new line' under WITH_PLUGINS - Add force:true on the .buttonicon-insertunorderedlist click to bypass #toolbar-overlay (same pattern as clearAuthorship and bold.spec). - Replace the keyboard.type('line 1'); keyboard.press('Enter'); keyboard.type('line 2'); keyboard.press('Enter'); sequence with a single writeToPad('line 1\\nline 2\\n') — insertText per line + Enter between, which Firefox under WITH_PLUGINS load handles without dropping events. The trailing newline preserves the final Enter the original spec relied on. Verified locally on Firefox + WITH_PLUGINS=1: passes in 8s. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): un-skip all 4 ordered_list tests under WITH_PLUGINS - issue #4748 + #1125: add force:true on .buttonicon-insertorderedlist clicks (toolbar-overlay interception after selection); collapse the per-line keyboard.type + keyboard.press('Enter') sequences into single writeToPad calls with embedded newlines. - issue #5160 and #5718 already used force:true and writeToPad throughout; just dropping the skip is enough now that the editor-ready helper landed. Verified locally on Firefox + WITH_PLUGINS=1: 11 passed (4 ordered_list + 5 unordered_list, plus 2 sub-describes). 1m24s total. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): un-skip all 4 indentation tests under WITH_PLUGINS Same pattern as bold/ordered_list/unordered_list: - force:true on .buttonicon-indent / .buttonicon-bold / .buttonicon-outdent clicks (toolbar-overlay interception after a text selection). - Replace per-line keyboard.type + keyboard.press('Enter') sequences with single writeToPad calls using \\n separators. - Replace single-character keyboard.type calls (':', '(', '[', '{{') with keyboard.insertText for consistency. The keypress and indent/outdent button tests were already passing without WITH_PLUGINS skips — only the four tests that race the toolbar click + typing sequence were skipped. With force:true and writeToPad they're stable. Verified locally on Firefox + WITH_PLUGINS=1: 12 tests pass across indentation, ordered_list, unordered_list, list_wrap_indent (matched by the indent grep). 1m11s total. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): un-skip enter.spec 'enter is always visible' under WITH_PLUGINS The test fired 15 keypress('Enter') calls in a tight loop with no per-iteration verify. Under Firefox + WITH_PLUGINS load the editor's input pipeline can't always keep up while plugin hooks are warming, so a few presses get dropped and the final `expect(div.count).toBe(numberOfLines + originalLength)` fails with too few lines. Add a value-driven `expect(div).toHaveCount(originalLength + i + 1)` after each press. The loop only advances once the editor has acknowledged the previous Enter, so dropped events become slow events instead of lost ones. Verified locally on Firefox + WITH_PLUGINS=1: passes in 11s (would have been 1.5m timeout previously). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): un-skip undo_clear_authorship under WITH_PLUGINS The two-user test was racing on User B's keyboard.type('Hello from User B') and 'Still connected!' — Firefox + WITH_PLUGINS load drops keystrokes from per-key events, leaving the second pad with truncated text that the body1 round-trip assertion never matches. Replace both keyboard.type calls with keyboard.insertText (single input event). Cannot use writeToPad here because the test relies on the caret position established by the preceding End + Enter — a writeToPad would re-click the body and reset focus. Verified locally on Firefox + WITH_PLUGINS=1: both tests pass clean in 30s (previously failed all retries at 1m+ each). The test.describe.configure({retries: 2}) is kept as belt-and-braces for the multi-context server propagation race that this test exercises legitimately. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): un-skip collab_client 'bug #4978 regression test' under WITH_PLUGINS The test's replaceLineText helper used keyboard.type(newText) to insert the replacement string after a Backspace clear. Firefox under WITH_PLUGINS load drops keystrokes from per-key events, leaving the line with truncated text that the cross-context assertions (body1.toHaveText(user2Text), body2.toHaveText(user1Text)) never match. Switch the type to keyboard.insertText (single input event) — same fix that unblocked ep_align in #7625 and the other typing-races in this branch. The selectText + Backspace + insertText pattern still exercises the legitimate collab race the test asserts (concurrent edits over the COLLABROOM). Verified locally on Firefox + WITH_PLUGINS=1: passes in 15s. This was the last of the 31 test.skip(WITH_PLUGINS, '#7611') markers in src/tests/frontend-new/specs/. The branch goal of zero #7611 skips is met. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): use stable l10n selector for OL toolbar button Qodo flagged the .first() call in #4748's setup as DOM-order dependent: a future plugin that adds another element carrying the .buttonicon-insertorderedlist class would silently change which button the test clicks. Switch to button[data-l10n-id='pad.toolbar.ol.title'] (the localizationId declared in src/node/utils/toolbar.ts), which is unique to the core ordered-list toolbar entry. Drop the now-unnecessary .first(). The class-based locator remains in #5160, #5718, and the indent/ outdent sub-describes; those don't strict-mode-match more than one element today, but a follow-up could swap them too for consistency if reviewers want. Verified locally on Firefox + WITH_PLUGINS=1: passes in 7s. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): tighten writeToPad Enter delivery + fix toolbar overlay regressions Three fixes for the failures that surfaced once #7630 ran in CI on Firefox + WITH_PLUGINS at the full matrix: 1. **writeToPad** now value-waits per Enter and retries up to 3 times if the editor doesn't acknowledge a new line. Long multi-line writes (e.g. timeslider_follow's #4389 setup with ~120 newlines) were dropping Enters faster than the previous single-press loop tolerated. The retry surfaces the canonical "expected N, got M" timeout if all 3 attempts fail. 2. **unordered_list.spec.ts**: every `.buttonicon-*` toolbar click now uses {force: true}. Two of the un-skipped tests intermittently missed the click under load because #toolbar-overlay intercepts pointer events after a text selection (same pattern as bold, ep_align, et al.). Body clicks (clicks inside the iframe pad body) are unaffected and stay as plain `.click()`. 3. **timeslider_follow.spec.ts** "regression test for #4389": re-skipped under WITH_PLUGINS with a specific note. The 120-Enter setup races plugin load even with the new writeToPad retry — re-press attempts overshoot the exact line count when a "dropped" Enter eventually lands. Needs a fundamentally different setup approach (REST API import, clipboard paste, etc.) to un-skip reliably; out of scope here. Net: 30 of the original 31 #7611 skips remain removed (was 31/31 before; the one re-skip is a documented known-aggressive case). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): revert writeToPad per-Enter retry — overshoots cause more failures The per-Enter value-wait + retry I added in fc45d71e5 was meant to catch dropped Enters in long multi-line writes, but in CI it made things worse: when a "dropped" Enter eventually landed during the retry's short poll window, the next iteration's exact line-count expectation was off by one and the retry loop overshot, breaking tests that previously passed (urls_become_clickable, language, inner_height all hit toHaveCount mismatches that didn't exist before). Revert to the simpler insertText + bare keyboard.press('Enter') loop. Tests with extreme line counts (timeslider_follow #4389, ~120 Enters) stay re-skipped from the prior commit; everything else accepts the same intermittent flake the helper exhibited before this fix attempt. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(playwright): re-skip 8 tests that need deeper rework to un-skip Honest scope adjustment after CI surfaced load-dependent failures that local single-run verification missed. The previous batches worked at low concurrency but flake at the full Playwright matrix under WITH_PLUGINS: - bold_paste.spec.ts — clipboard / paste race between specs - collab_client.spec.ts (bug #4978) — multi-context cross-pad propagation under load - enter.spec.ts (enter is always visible) — 15-Enter loop drops presses faster than the per-iteration value-wait can recover - timeslider_follow.spec.ts (content as it's added) — 66 sequential Enters across 6 writeToPad calls - undo_clear_authorship.spec.ts (describe-level) — multi-context; the cross-pad text-arrival assertion races - undo_redo_scroll.spec.ts (describe-level) — 45-line writeToPad setup; scroll-position assertion needs stable layout - unordered_list.spec.ts (Keeps unordered list on enter) — toolbar click + writeToPad with embedded newline races All carry inline comments explaining the specific load issue and referencing #7611 so a follow-up that introduces a REST-driven or clipboard-paste setup mechanism can target them concretely. Net: 23 of 31 #7611 skips removed (74%). The deferred 8 share two underlying limitations that need infrastructure work: 1. No reliable way to drive >10 sequential Enters under load without occasional drops 2. No reliable cross-context propagation wait helper Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * DO-NOT-MERGE bisect plugins: Firefox×HALF-A + Firefox×HALF-B One CI run, both halves of the standard plugin set, both on Firefox (which is the project that reliably trips the flake we're chasing). Playwright Firefox with plugins → HALF A: ep_align, ep_author_hover, ep_cursortrace, ep_font_size, ep_headings2 Playwright Chrome with plugins → HALF B: ep_markdown, ep_readonly_guest, ep_set_title_on_pad, ep_spellcheck, ep_subscript_and_superscript, ep_table_of_contents (job runs --project=firefox here too) Decision matrix on next CI: - Both fail → load alone is the cause; deeper rework needed. - Only A fails → culprit is in HALF A (5 candidates). - Only B fails → culprit is in HALF B (6 candidates). - Both pass → flake threshold sits between 5–6 plugins; the culprit is whichever 2-plugin pair from the full set tips the load above threshold; iterate. Revert this commit before merging — it's purely a CI probe. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * DO-NOT-MERGE bisect plugins iter 2: A1 (align,author_hover) vs A2 (cursortrace,font_size,headings2) Iteration 1 isolated to HALF A. Splitting: Playwright Firefox with plugins → A1: ep_align, ep_author_hover Playwright Chrome with plugins → A2: ep_cursortrace, ep_font_size, ep_headings2 (still --project=firefox) Decision matrix: - Both fail → load alone tips it; ≥2 of these 5 are needed. - Only A1 fails → culprit is ep_align or ep_author_hover. - Only A2 fails → culprit is ep_cursortrace, ep_font_size, or ep_headings2. - Both pass → flake threshold is between 2 and 3 plugins from A, revisit splitting (could be a specific pair). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * DO-NOT-MERGE bisect plugins iter 3: A2a (cursortrace) vs A2b (font_size, headings2) Iteration 2 isolated to A2 (cursortrace+font_size+headings2). Iter 3 singles out ep_cursortrace: Playwright Firefox with plugins → A2a: ep_cursortrace Playwright Chrome with plugins → A2b: ep_font_size, ep_headings2 (still --project=firefox) Decision matrix: - Only A2a fails → ep_cursortrace is the culprit (1 plugin alone tips it). - Only A2b fails → culprit is ep_font_size or ep_headings2. - Both fail → load tips at >=1 plugin from this set; investigate each individually. - Both pass → load tips at >=3 plugins; revisit splitting. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * DO-NOT-MERGE bisect plugins iter 4 (confirm): all-minus-cursortrace Iter 3 isolated to ep_cursortrace alone. Confirming by running the inverse — every other plugin in the standard set, no ep_cursortrace — on TWO Firefox runs in parallel: Playwright Firefox with plugins → align, author_hover, font_size, headings2, markdown, readonly_guest, set_title_on_pad, spellcheck, subscript_and_superscript, table_of_contents Playwright Chrome with plugins → same 10 plugins (still --project=firefox per probe) Both pass → ep_cursortrace is conclusively the culprit. Either fails → load is the cause and the bisection mis-attributed (would need to investigate why iter 3 cursortrace-only failed: maybe a flaky one-off). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * ci(frontend-tests): exclude ep_cursortrace from with-plugins set Bisected via 4 CI iterations on this branch. ep_cursortrace's `aceEditEvent` hook (static/js/main.js in the plugin) fires on every keyboard event — handleClick, handleKeyEvent, idleWorkTimer — and unconditionally sends a `cursorPosition` socket message via `pad.collabClient.sendMessage` per call. Under the test harness's writeToPad bursts (insertText + Enter loops) that stream of socket messages saturates the editor's input pipeline in Firefox specifically, causing intermittent keystroke drops and the entire class of #7611 flakiness this PR was originally chasing. Confirmation runs: - 11-plugin set including ep_cursortrace → fails on Firefox - HALF B (5 plugins, no cursortrace) → passes - HALF A (5 plugins, with cursortrace) → fails - A1 (align, author_hover) — no cursortrace → passes - A2 (cursortrace, font_size, headings2) → fails - A2a (cursortrace alone, 1 plugin) → fails - A2b (font_size, headings2, no cursortrace) → passes - 10-plugin set, all minus ep_cursortrace → passes (×2 jobs) Drop ep_cursortrace from the frontend-tests.yml plugin set and restore all the un-skips that this PR pessimistically re-skipped during the load-symptom whack-a-mole. The plugin itself needs a debounce/throttle around its socket send before it can come back into the test set; tracked separately in the ep_cursortrace repo. Backend tests / docker / etc remain on the original 11-plugin set since they don't trip the same input-pipeline race. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
9a9659c110
|
feat(editor): add showMenuRight URL param to hide right-side toolbar (#7553)
* feat(editor): add showMenuRight URL param to hide right-side toolbar Adds a showMenuRight URL/embed parameter. When set to false, the right-side toolbar (.menu_right — import/export, timeslider, settings, share, users) is hidden. Default behavior (menu shown) is unchanged. Motivated by read-only / announcement-pad embeds where viewers shouldn't see those controls, but the same server hosts editable pads where the buttons must remain available (so globally disabling them in settings.json is not a fit). Closes #5182 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(editor): auto-hide menu_right on readonly pads, accept showMenuRight=true override Addresses Qodo review feedback on #7553: 1. Readonly pads now hide the right-side toolbar automatically. The original issue (#5182) was specifically about readonly embeds; the previous implementation only honoured an explicit `?showMenuRight=false` URL parameter, which meant that vanilla readonly pads still showed import/export/timeslider/settings/share/users controls — all noise for viewers who can't interact with the pad anyway. 2. Callers who still want the menu visible on readonly pads can opt back in with `?showMenuRight=true`. The URL-param callback now accepts both values instead of just `false`. 3. The Playwright spec's `browser.newContext() + clearCookies()` pattern was a no-op because the test navigated with the existing `page` fixture (different context). Switch to `page.context().clearCookies()`, and cover both the auto-hide and the explicit-override paths on a readonly-URL navigation. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(7553): use actual readonly-URL selector in Playwright spec The previous test looked up (capital-I) and called inputValue() on it. The real element is (lowercase) and it's a toggle checkbox, not a URL field. The readonly URL itself is in `#linkinput`, updated live when the readonly checkbox is checked. Wire the test to that flow. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(7553): wait for share popup before clicking readonly checkbox Playwright's stability check kept retrying the click while the popup was animating open ("element is not stable"). Wait for #embed.popup-show and use click({force: true}) so a trailing CSS transform doesn't retrigger the instability backoff. Also wait for #linkinput to update to the readonly URL before reading it — the checkbox change is asynchronous. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
884ac93b4e
|
feat(editor): add IDE-style line ops (duplicate / delete) (#7564)
* feat(editor): add IDE-style line ops (duplicate / delete) Addresses #6433 — the issue asked for VS-Code-style multi-line editing for collaborative markdown editing. Full multi-cursor support would need a rep-model rewrite; this PR lands the two highest-value single-cursor line ops now so users get the actual ergonomic wins without that lift: - Ctrl/Cmd+Shift+D: duplicate the current line, or every line in a multi-line selection. Duplicates land directly below the original block, so the caret visually stays with the original content — same as VS Code / JetBrains. - Ctrl/Cmd+Shift+K: delete the current line (or every line in a multi-line selection), collapsing the range including its trailing newline. Handles edge cases: last-line selections consume the preceding newline; a whole-pad selection leaves one empty line behind (Etherpad always expects at least one). Both ops run through `performDocumentReplaceRange`, so they're collaborative-safe: other clients see the change arrive as a normal changeset, and the operation is a single undo entry. Wire-up: - `src/node/utils/Settings.ts`: extend `padShortcutEnabled` with `cmdShiftD` / `cmdShiftK` (both default true so fresh installs get the feature without config; operators who pin shortcut maps can disable them individually). - `src/static/js/ace2_inner.ts`: new `doDuplicateSelectedLines` / `doDeleteSelectedLines` helpers, exposed on `editorInfo.ace_*` so plugins and tests can invoke them programmatically, and keyboard handlers for Ctrl/Cmd+Shift+D and Ctrl/Cmd+Shift+K. Test plan: Playwright spec covers the three interesting paths (single-line duplicate, single-line delete, multi-line duplicate). Closes #6433 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(6433): type the bodyLines helper parameter * fix(6433): preserve char attributes on duplicate + correct whole-pad delete Addresses Qodo review feedback on #7564: 1. `doDuplicateSelectedLines` was inserting raw line text via `performDocumentReplaceRange`, which carries only the author attribute — every other character-level attribute on the source line (bold, italic, list, heading, link) was dropped, and in some cases Etherpad's internal `*` line-marker surfaced as literal text. Rewrite to build the changeset directly: walk each source line's attribution ops from `rep.alines[i]`, split the line text at op boundaries, and call `builder.insert(segment, op.attribs)` once per op. Each attribute segment from the source ends up on the duplicate verbatim. Wrapped in `inCallStackIfNecessary` for the standard fastIncorp + submit cycle. 2. `doDeleteSelectedLines` whole-pad case deleted from `[0, 0]` to `[0, lastLen]` even when the selection spanned multiple lines, leaving later lines in place and sometimes producing an invalid range when `lastLen` exceeded line 0's width. Change to `[end, lastLen]` so every selected line is cleared, with one empty line retained for the final-newline invariant. 3. Added `ace_doDuplicateSelectedLines` / `ace_doDeleteSelectedLines` entries to `doc/api/editorInfo.md` so plugin authors can discover the new surface. 4. New Playwright spec asserting `<b>` tags survive duplication. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * revert(6433): drop the attributed-duplicate changeset, keep whole-pad delete fix The attributed-changeset rewrite for doDuplicateSelectedLines tripped over the insertion-past-final-newline edge case — CI caught the basic single-line duplicate regressing (gamma → [alpha, beta, gamma] with no new gamma appearing because the hand-rolled changeset ended up invalid at the end-of-pad boundary). performDocumentReplaceRange handles that edge case internally, but only with a uniform author-attribute insert. Revert duplicateSelectedLines to the simpler performDocumentReplaceRange form that CI was happy with. Flag the attribute-preservation gap explicitly in the code so a follow-up can bolt on a proper attributed insert without re-inventing the end-of-pad handling. Whole-pad delete fix and editorInfo.md docs stay. Attribute-preservation test in line_ops.spec.ts is removed along with the broken code. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
John McLear
|
6c9ed46957
|
test: use selectAllText helper instead of raw Control+A in timeslider spec (#7629)
Under Firefox + WITH_PLUGINS the keyboard.down/press/up('Control')
chord races with the focus delegation into the inner ace iframe and
can drop either the Control or the A keystroke, so the subsequent
Backspace deletes a single character rather than the line and the
"delete everything" revision the test relies on never gets created.
selectAllText runs inside the inner frame's selection model, which
isn't subject to that race.
Resolves the firefox failure on
'timeslider playback advances through all revisions including
identity changesets' tracked in #7626.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
John McLear
|
0a2facb3fc
|
ci(packaging): publish signed apt repository to etherpad.org/apt (closes #7610) (#7624)
* ci(packaging): publish signed apt repository to etherpad.org/apt (closes #7610) Adds an `apt-publish` workflow job that turns the existing `.deb` build artefacts into a signed apt repository hosted at: https://etherpad.org/apt/ End-user install on any Debian/Ubuntu/Mint: curl -fsSL https://etherpad.org/key.asc \ | sudo gpg --dearmor -o /usr/share/keyrings/etherpad.gpg echo "deb [signed-by=/usr/share/keyrings/etherpad.gpg] \ https://etherpad.org/apt stable main" \ | sudo tee /etc/apt/sources.list.d/etherpad.list sudo apt update && sudo apt install etherpad `apt upgrade` works going forward — every tagged release republishes the repo metadata. Change type: patch (CI/distribution; no production behaviour change). ## Why etherpad.org/apt and not ether.github.io/etherpad/apt ether/etherpad's GitHub Pages is already configured as build-from-workflow on `develop` with CNAME `docs.etherpad.org`, and a repo can only have one Pages source. Pushing the apt repo to a gh-pages branch would either be ignored (Pages is reading from the docs workflow) or, if Pages were switched to it, would kill the docs site. ether/ether.github.com is a separate Next.js site that already deploys etherpad.org and serves `public/` verbatim, so cross-pushing the apt repo into `public/apt/` lands it at the canonical Etherpad URL with no infrastructure conflicts. ## What this PR ships 1. `apt-publish` job in `.github/workflows/deb-package.yml`. Runs after `release` on `v*` tag pushes: - Clones ether/ether.github.com over SSH using a deploy key. - Wipes site/public/apt/ and rebuilds it from the per-arch .deb artefacts using apt-ftparchive. - Signs Release + emits InRelease/Release.gpg using the keypair in APT_SIGNING_KEY. - Drops key.asc into site/public/key.asc. - Asserts both per-arch .debs are present before the wipe takes effect — refuses to publish a partial / empty repo if an artefact is missing or renamed. - Commits and pushes to master; the site repo's existing build pipeline picks it up. 2. `packaging/apt/key.asc` — Etherpad APT Repository public key, fingerprint 6953FA0C6431F30347D65B03AF0CD687D51A6E63. Served at https://etherpad.org/key.asc after the next release. 3. `packaging/apt/generate-signing-key.sh` — one-shot helper that generated the keypair, kept for documented future rotation. 4. `packaging/README.md` — apt-repo install recipe is now the recommended path. ## Required secrets before the next tagged release Two secrets on ether/etherpad before the next `v*` tag push: - APT_SIGNING_KEY — ASCII-armoured private key for the Etherpad APT Repository keypair (long key id AF0CD687D51A6E63), generated with packaging/apt/generate-signing-key.sh. - SITE_DEPLOY_KEY — SSH private key. The public half registered as a deploy key with WRITE access on ether/ether.github.com. If either is missing the job fails fast with a clear error. ## What this PR does not change - The release job still attaches both versioned (etherpad_<v>_<arch>.deb) and stable-aliased (etherpad-latest_<arch>.deb) artefacts to the GitHub Release. Anyone pulling from releases/latest/download/etherpad-latest_amd64.deb keeps working. - The build-job smoke test (start under systemd, /health, purge) is unchanged. - docs.etherpad.org is untouched; this PR never pushes to gh-pages. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * ci(packaging): emit unindented Release headers + tighten artefact glob Two corrections from a fresh Qodo review of the rebased apt-publish job: 1. The dists/${SUITE}/Release heredoc was indented with the workflow's YAML scope, which means the resulting file had 10-space-prefixed field lines (` Origin: Etherpad`). apt parsers reject any leading whitespace on header fields per RFC 822 / Debian control format, so the entire suite would have failed to parse on `apt update` even before checksums were appended. Replace the heredoc with `printf '%s\n' ...` so the indentation is entirely under workflow control and impossible to break with a future YAML re-indent. 2. Tighten the artefact glob from `etherpad_*_amd64.deb` to `etherpad_[0-9]*_amd64.deb`. The hyphen-separator distinction (etherpad_<v>_… vs etherpad-latest_…) already kept the alias out of the array — Qodo's analysis of a duplicate-Packages bug was incorrect. But pinning to a leading-digit version segment makes the contract explicit and defends against any future alias that accidentally lands on `dist/etherpad_<word>_<arch>.deb`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
SamTV12345
|
c55007361c
|
chore: updated node to supported 22,24,25 (#7628)
* chore: updated node to supported 22,24,25 * chore: updated node to supported 22,24,25 * chore: updated node to supported 22,24,25 * chore: updated node to supported 22,24,25 * chore: upgrade deb * chore: upgrade dockerfile * chore: use explicit node * chore: use node 22 * chore: use node 22 |
||
|
dependabot[bot]
|
421869daec
|
build(deps): bump actions/upload-artifact from 4 to 7 (#7612)
Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 4 to 7. - [Release notes](https://github.com/actions/upload-artifact/releases) - [Commits](https://github.com/actions/upload-artifact/compare/v4...v7) --- updated-dependencies: - dependency-name: actions/upload-artifact dependency-version: '7' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
SamTV12345
|
74d1715c1b
|
chore: updated clients to esm (#7627) | ||
|
John McLear
|
f6a56ec2cb
|
test(playwright): use insertText so Firefox stops dropping keystrokes (#7625)
writeToPad has been calling page.keyboard.type, which fires one keydown/keyup per character against the contenteditable. Under WITH_PLUGINS load Firefox's input pipeline can't keep up with the per-event firing while plugin hooks are still warming, and randomly swallows characters from the tail of the string — pad ends up with e.g. "aligned tex" instead of "aligned text". The dropped character is irrecoverable: there is no event 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 result is identical to what real typing produces — minus the per-key race. insertText does not translate \n into Enter (it concatenates "One\nTwo" into "OneTwo"), so split on newlines and press Enter between segments to preserve multi-line input that the existing callers (timeslider_line_numbers, page_up_down, etc.) rely on. Verified locally on Firefox + WITH_PLUGINS: - ep_align Alignment: 4/4 pass (previously 0/4 even after retries) - italic.spec: 2/2 pass - timeslider_line_numbers (multi-line): pass Chromium remains green. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |