Bug: Text selection on safari has extra empty selection area

[alterhuman]

Selection a text node in safari you can also select the area between 2 text nodes. While selecting, you first select the text then you can also select the empty area above/below the node and then you select the next node. This is lexical playground:

The selection works correctly on Chrome:

This is a lexical issue because it doesn't exist in other text editors, for example in the GitHub text editor itself.

[levensta]

Still actual bug but we need to make sure that this is relevant only for the playground or not

[pro-vi]

WebKit paints the native ::selection highlight across the whole block box, not the glyph box, so a short line (and any triple-click select-paragraph) fills to the full line-box width and bleeds into the empty space past the text. Chromium and Firefox clamp the paint to the text run, which is why it reproduces only on Safari / WKWebView. The "extra empty selection area" is two things stacked: that block-box paint, plus a spurious WIDER rect that getClientRects() emits alongside the real text rect on some blocks (balanced / tracked headings are the reproducible case).

There is no CSS fix for the native paint, ::selection can recolor the fill but cannot constrain WebKit's block-box width back to the glyph box. The only complete fix is the CodeMirror drawSelection approach: stop relying on ::selection and draw your own rects from the selection's text client-rects.

We hit this in a Tauri / WKWebView build of a Lexical editor and shipped a fix. It has two layers. The small part is rect-deduping: drop zero-area rects and any rect that contains another (keep the smaller, text-hugging one), which also removes the spurious-wider rect and the doubled-opacity duplicates, and which helps every current fake-selection consumer (markSelection, selectionAlwaysOnDisplay) on WebKit. The real part is drawing the FOCUSED selection on WebKit too and hiding the native paint via background-color: transparent on ::selection, gated to IS_APPLE_WEBKIT so Chromium/Firefox keep their correct native selection. The focused-draw needs rAF-coalescing to avoid a one-frame flash on triple-click (WebKit over-selects, Lexical corrects it the same tick).

Opened a draft PR for the dedupe half: #8709. It adds dedupeSelectionRects and runs positionNodeOnRange's rects through it (so markSelection / selectionAlwaysOnDisplay are cleaner on WebKit too), with the registerDrawSelection approach for the focused selection written up in the description as a follow-up since it is a new API surface. The dedupe could merge on its own; the draw-replacement is the actual close. Thanks for the rect-drawing machinery already being in @lexical/utils, most of the real fix is wiring it for the focused case.