Skip to content

Version 1.3.13 - #614

Merged
maboa merged 3 commits into
mainfrom
release/1.3.13
Aug 31, 2026
Merged

maboa merged 3 commits into
mainfrom
release/1.3.13

Conversation

@maboa

@maboa maboa commented Aug 31, 2026

Copy link
Copy Markdown
Member

Seven fixes, two of them Safari-only, and one change every existing user will see.

Fixes #602, #603, #604, #605, #611, #612, #613

Gate: 105 unit, 290 e2e passed, 1 skipped, plus the known clipboard flake (#606).

maboa added 3 commits August 31, 2026 20:00
Striking a word in Safari also struck the word before it. Chrome was
unaffected, and a double-click was unaffected in both, which is what kept
it hidden.

applyStrikeThroughToSelection collects spans with intersectsNode(), which
is true for a span the range merely TOUCHES — and the engines anchor a
drag differently when it starts on a word's first letter:

  WebKit    selected "charlie"  anchored in text("bravo ")@6   <- previous
  Chromium  selected "charlie"  anchored in text("charlie ")@0

So in WebKit the previous span held the range's start boundary while
contributing no characters. The leading-space trim could not notice: the
selected string is "charlie" with no leading space, because the space sits
BEFORE the anchor, inside the previous span. That trim handles a drag that
runs INTO the previous word's trailing space — a different case, still
working.

A span now has to contribute text: clamp the selection to the span and ask
whether any non-whitespace remains. Only like-for-like boundary
comparisons (START_TO_START, END_TO_END), which are unambiguous, with a
fallback to the old inclusive behaviour if the boundaries are ever
unexpected.

Measured as a matrix in both engines. Before: WebKit wrong on all three
drag variants, right on double-click; Chromium right on all four. After:
all eight correct, Chromium unchanged throughout — an engine-specific
anchoring difference should not alter the other engine. The spec runs
both, and defanged it fails ONLY the WebKit case, on the drag-from-the-
first-letter assertion.

Not a recent regression as far as I can tell: editor-audio-cut.js has not
changed since v1.3.12, and this rests on WebKit's anchoring rather than
anything new.

Two things fixed alongside:

- editor-audio-cut.js kept its 1.3.9 cache stamp while its contents
  changed, so Safari served the old file and the fix appeared not to work.
  Second time today (the first was #602's save.js); bumping belongs at the
  moment a file changes, not at release, or local testing is against a
  stale file and can mislead in either direction.
- #604's "a slow host does not delay the panel" asserted a 900ms render
  against a 1200ms host. Too tight: it failed in a loaded gate run AND in
  isolation, so it had been passing by luck. The host now stalls 6000ms
  against a 3000ms window — the point is that the panel does not wait, not
  that it renders within any particular millisecond.

Fixes #613

Gate: 105 unit, 290 e2e, 1 skipped, plus the known clipboard flake (#606).
@maboa
maboa merged commit 3789b3b into main Aug 31, 2026
1 check failed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

The intro should be an ordinary project, present in Recents

1 participant