[mike-doctorina]

Supersedes #27 — same work, reviewed, with the defects fixed and the two unrelated features carved off into #28 and #29. Opened here so it is not blocked on a fork branch.

Credit: the feature work is @itsezlife's (9 commits, preserved verbatim at the base of this branch). Everything on top is review follow-up.

What it does

Brings the controller-driven selection path up to Flutter SelectionArea / SelectableRegion quality without wrapping markdown in a SelectionArea:

• Chrome parity — soft-wrap affinity on handles, directed base/extent edges with reversed handle types, coincident-caret separation, handle proxies when an endpoint surface unmounts, native SelectionOverlay handles + magnifier on touch.
• Desktop parity — mouse drags, double/triple clicks, Cmd/Ctrl+A and programmatic selection no longer pop the toolbar; right-click opens the menu without mutating the selection; the menu keeps its right-click anchor and dismisses on ancestor scroll.
• Host gates for chat mounts — enableTouchGestures, enableTouchConsecutiveTaps, ownsSelectionChrome, canStartSelectionAt.
• Glyph-tight hit testing — hover I-beam and link hits use rendered line boxes, not the full max-width layout; gesture starts stay surface-bounds.
• Highlight paint — stays outside the glyph Picture cache, under the glyphs by default, with a second pass above opaque chrome (code fences, table zebra rows, inline monospace).
• Registry — removeDocument defers while a surface is mounted; rangeFor and ordering ignore unregistered ids instead of treating them as index -1.
• Fenced code inside quotes / alerts — re-parsed as nested MD$Code in MD$Quote.blocks / MD$Alert.blocks instead of being eaten as inline monospace by backtick pairing.
• Edge autoscroll while dragging near the viewport edge.

What changed versus #27

Eight defects, each with a regression test that failed before the fix:

1. Registry corruption on element recycling — updateRenderObject pushed the new model before rewiring the id, so a ListView.builder reusing a slot wrote message B's body under message A's id. Silent, and it hits exactly the virtualized-chat case this is built for.
2. setState() called during build — onSelectionChanged fired synchronously from inside build/layout on two ordinary paths (a streaming putDocument from updateRenderObject, a deferred removeDocument flushing from RenderObject.detach). Delivery is now coalesced to the end of the frame in those phases.
3. canStartSelectionAt refusal left the drag armed — a long press on refused chrome kept extending the active selection from that point.
4. Heal-registration jumped to the front of the conversation — putDocument with no order used _docs.length, which sorts ahead of sparse explicit orders.
5. Unstable order tie-break — List.sort is not stable, so documents sharing an order could swap on any re-sort and reverse extracted text.
6. Glyph boxes recomputed on every hover event — now cached per TextPainter layout.
7. maxVelocity: 0 spun the frame ticker forever.
8. Nested quote/alert children bypassed MarkdownThemeData.builder — a host that replaces the code painter lost it inside > ….

Autoscroll no longer speaks the sliver protocol

The band / host-union / arming math ran against ScrollableState and ScrollPosition.jumpTo, so it could not drive our own chat viewport, which owns an anchor offset and has no Scrollable in the tree at all. It now runs against a MarkdownAutoscrollTarget:

Member	Meaning
MarkdownAutoscrollViewport? get viewport	visible global bounds + the inset where the bands start
bool canScroll({required bool forward})	can a positive / negative delta still move content
double applyScrollDelta(double delta)	move content by screen-space pixels; return what was applied (0 hard-stops and disarms)

MarkdownScrollableAutoscrollTarget keeps today's behaviour and fixes reverse: true lists (AxisDirection.up), which most chats use and the old sign handling got wrong. MarkdownSelectionAutoscrollConfig.targetResolver + MarkdownCallbackAutoscrollTarget cover everything else, and useHostUnionGate: false exists because the union gate assumes a cache extent — a viewport that builds only what is visible would have its own paging vetoed.

The surface is also resolved once per drag now, instead of two full element-subtree walks per frame.

Coverage

The streaming corpus had quote, quote-multi and two alerts but no body containing a fence — the one construct that makes the decoder re-enter itself, and the one the chat streams straight into. Added six documents; incremental matches batch on every prefix across all six chunkings.

1080 → 1222 tests (after moving 27 of them to #28 / #29). dart analyze --fatal-infos --fatal-warnings lib/ test/ clean, dart format clean, flutter build web on the example passes.

Breaking vs 0.2.0

Written out in the changelog. Source-breaking only for hosts that implement the render / selection extension points:

• removed BlockPainter$Quote.painter, BlockPainter$Alert.bodyPainter;
• both painters now mix in MultiPainterSelectable instead of SelectableTextBlock;
• SelectableBlockPainter gained 4 members, MarkdownSelectionSurface gained 7 (the mixins cover anyone using them; direct implementers must add them);
• MarkdownThemeData.copyWith returns MarkdownThemeData instead of the base ThemeExtension.

Please eyeball on a device before merge

Genuinely unverifiable in widget tests:

• Handle chrome — affinity, directed edges, coincident-caret separation, proxies, multi-scope LayerLink ownership. The most intricate code here, and its failure modes are visual: two handles stacked at one caret, a ghost handle after remount, a handle on the wrong side.
• Desktop toolbar anchors — toolbarHeight = 48.0, aboveGap = 8.0 and friends are pinned numerically but nothing checks the menu stays on screen.
• Autoscroll feel — the quadratic ramp and the edgeZone / maxVelocity defaults.

Targets: iOS, Android, mobile web, desktop web.

[itsezlife]

Two toolbar timing bugs from dogfooding this branch with several MarkdownSelectionScopes on one controller. Landed together as #33 against this tip.

Ownership loss. When selection moves from A to B, scope A cleared handles but left the adaptive toolbar up. _updateHandlesAndOverlay only called _clearHandles() when !_handlesEnabled. _onControllerChanged only refreshed or hid the menu for an owning scope with toolbarWanted, so a non-owner with an already-shown menu never called _contextMenuController.remove().

Fix: if !_ownsChromeForCurrentSelection, remove this scope's context menu without clearing toolbarWanted. Same when handles are disabled for that reason. Regression in selection_host_gates_test.

Mid-drag scroll restore. Expand drag + edge autoscroll could re-show the toolbar before release. Scroll notifications hit the geometry restore path, and toolbarWanted was enough to present the menu. A host that clamps a cross-document wander back onto the subject via the public selection setter re-arms toolbarWanted mid-gesture, so the menu came back early.

Fix: _onScrollAffectingChrome / _refreshToolbarForVisibleGeometry / _scheduleToolbarGeometryRefresh no-op while _dragGlobal is set. Regression in selection_widget_test (expand drag keeps toolbar hidden across scroll even if toolbarWanted is re-armed mid-drag).

I cannot push to DoctorinaAI/md from here. Verified in the chat viewport for both cases. The host also clears toolbarWanted on subject adopt and after a same-document clamp restore so the new scope does not restore mid long-press.

[itsezlife]

I've verified the new autoscroll works perfectly in the chat environment. Would let you know whether it behaves identically in my domain application with regular text selection inside sliver protocol.