Keep non-rendered text out of comment anchors

[kelchou]

Example link to issue: https://coplan-square.sqprod.co/plans/019faa9b-4de6-7d61-9f4b-be329aacafa2

Problem

Mermaid diagrams on a plan can render as unstyled black shapes — big black node boxes and black-filled edge paths — while the same plan looks fine for other people.

The trigger is a comment whose anchor was captured by sweeping a selection across a diagram. checkSelection extracts anchor text with range.cloneContents().textContent, and textContent includes the <style> sheet Mermaid embeds inside its SVG even though that text never renders. The stored anchor then carries several KB of theme CSS.

On every subsequent visit, highlightAnchors() matches that anchor against contentTarget.textContent (which also contains the CSS), and highlightAtIndexAll()'s TreeWalker wraps <mark> elements around text inside the <style> element. A <style> only parses its direct child text, so the re-parented chunk silently drops out of the sheet — the whole diagram loses its stylesheet and falls back to SVG defaults: black fills everywhere.

The corruption is theme-dependent, which disguises it as a light/dark bug: the anchor stores the CSS text of whichever theme was active at capture time, so it only re-matches (and only corrupts) when the diagram renders in that same theme. In the observed case the anchor held light-theme CSS — light-mode viewers got a black diagram, dark-mode viewers saw it fine.

Fix

Define one rendered-text model — every text node under the content target except those inside style/script/noscript — and use it at every site that computes text offsets:

• checkSelection (anchor capture): strips non-rendered elements from the cloned fragment before reading textContent, so new anchors can never embed CSS.
• extractContext, computeOccurrence, getSelectionOffset, scrollToAnchor, highlightAnchors, highlightAtIndexAll: all walk the same _renderedTextNodes() sequence, so offsets stay mutually consistent and marks can never be wrapped inside a <style>.

Existing anchors that already carry CSS text simply stop matching, which degrades to the standard "content changed → no highlight" behavior instead of corrupting the page. The threads themselves remain fully usable from the sidebar.

Verification

System specs (spec/system/mermaid_anchor_spec.rb, added in this PR): two regression tests driving the real pipeline — Mermaid rendered in the browser, real controllers. A stored anchor carrying stylesheet text must leave the SVG <style> free of marks with its sheet parseable (while label and prose anchors keep highlighting), and a selection swept across a diagram must capture visible text without CSS. Both fail against the previous controller — the capture test reproduces the exact poisoned-anchor shape observed in production (The diagram #coplan-mermaid-1{font-family:...) — and pass with the fix. Full suite run locally: the only failures are pre-existing on main (request/service specs unrelated to this change).

Browser harness against a real production plan page (71 comment threads, 4 Mermaid diagrams, 2 CSS-poisoned anchors), running Mermaid 11.16.0 with the exact controller config:

	old text model	fixed text model
marks landing inside a diagram <style>	2	0
diagram stylesheets intact after highlight pass	0 of 4	4 of 4
legitimate anchors still highlighted	31	31 (same set)
anchors matching at all	32	31 (only the CSS-poisoned anchor stops matching)

Visually confirmed: the affected flowchart renders fully styled in light mode after the fix, with prose anchor highlights still working.

🤖 Generated with Claude Code