docs/solutions/logic-errors/2026-04-04-slate-browser-playwright-helpers-must-normalize-zero-width-selection-and-wait-for-selection-sync.md
The first real slate-browser Playwright tranche exposed two fake assumptions
at once:
Cmd/Ctrl+AOn the empty placeholder path, the browser caret really sits inside the FEFF
marker at native offset 1.
That is fine for DOM assertions. It is wrong for Slate assertions.
On the rich copy path, DOM selection looked expanded immediately, but Slate’s
copy handler still needed a short settle before synthetic copy captured the
real payload.
Without normalization, assertSelection(...) lies about Slate semantics on the
exact zero-width path the browser framework is supposed to pin.
Without the settle, synthetic copy tests look random:
That is how bad helper APIs create bullshit failures.
assertDomSelection(...) returns raw browser offsetsassertSelection(...) maps FEFF zero-width native offset 1 back to
Slate offset 0selectAllInEditor(...) as asynchronous editor work, not an instant
fact:
copy event with an instrumented clipboardData
sinkFor Slate browser helpers:
Cmd/Ctrl+AIf a helper returns native FEFF offset 1 and calls it a Slate selection, or
fires copy immediately after select-all, the helper is the bug.