fix(reading-mode): nest the task card inside the header so virtualisation cannot delete it

[nelsonlove]

Fixes #2255.

The problem

Reading mode is virtualised, and every render pass ends with sizerEl.setChildrenInPlace([pusherEl, ...shownSections]), which deletes any direct child of .markdown-preview-sizer that Obsidian did not put there. The task card is injected between sections, so it is deleted on every pass and re-injected on the next frame. During a scroll that cycle runs continuously and drags the reader down the note until it hits the bottom.

The scroll quiet period added in b29a29e defers re-injection, but it cannot stop this, because the problem is where the re-injection lands rather than how often it happens. Once the reader has scrolled past the top of the note, Obsidian has detached .mod-header.mod-ui too, so getMetadataOrHeaderInsertionReference falls through to the preview pusher - whose next sibling is the first section that is currently rendered, not the first section of the note. The card is therefore inserted into the middle of the text being read, and shoves the page down by its own height.

Measured on 4.12.5 by wrapping the scroller's scrollTop setter and capturing a stack on every write. One caller dominates:

e.updateVirtualDisplay  <-  e.onScroll

and the corrections are a constant step that repeats to the bottom of the note. The step equals the card's own occupied height, on each note:

note	card occupied height	correction step
A	579px	+578 / +579
B	690px	+690 / +698

The corrections arrived every 218-262ms, which is DEFAULT_SCROLL_QUIET_PERIOD_MS plus a frame. The quiet period did not stop the cycle; it set its tempo.

The change

setChildrenInPlace only manages direct children, so nesting the card one level deeper leaves it untouched by the render pass. It is now placed inside the header, after the properties block.

Issue #2255 raised this route and found it insufficient on its own, which was correct: .mod-header.mod-ui is itself sections[0], so Obsidian detaches it - with the card inside - when the reader scrolls past the top, and the observer then re-injects as a direct child and restarts the cycle. Two supporting changes close that:

• The observer skips re-injection while the header is not rendered. That detach is Obsidian's own virtualisation and must be left alone rather than fought. The card is restored when the header comes back, which is exactly when it can be seen.
• Injection anchors on the properties block, not the end of the header. Obsidian builds the header in stages, so appending during an early pass put the card above the properties, which then rendered underneath and shoved it down - a visible jolt on every note open.

Nesting also corrects the height accounting noted in the issue: measureSection takes a section's height as the gap between its own offsetTop and its next sibling's, so a widget between sections is counted in neither. Inside the header it is counted in that section.

Tests

tests/unit/editor/MarkdownWidgetInsertion.test.ts pins the mechanism rather than the implementation, by simulating a render pass:

• a widget placed between sections is deleted by it
• a widget nested in the header survives it
• with the header detached, the old insertion reference resolves to the first rendered section - the trap this fixes
• with the header present but the properties block not yet rendered, injection is refused rather than landing above it

33 tests pass across all 6 editor suites.

Verification

Built and run against a real vault on 4.12.5. The runaway is gone, the card holds its position under scrolling, and it renders once in its final place with no jolt.

Trade-offs, stated plainly

• The card is absent while the reader is scrolled past the top of the note. It is inside the header, and Obsidian detaches that section. This is invisible in practice - the card lives at the top, so it cannot be seen from further down - but it is a real behaviour change from "always in the DOM".
• Requiring the properties block means a task note that renders in reading mode with no .metadata-container at all would not receive a card. If that case exists, a fallback to the end of the header once the header is known to be complete would cover it.
• The :has() selector that trims the properties block's bottom margin needs Chromium 105+. Where it does not apply, the gap is simply larger; nothing breaks.

Spacing is scoped to .markdown-preview-view .mod-header, so Live Preview and canvas are unchanged. The gap below the card uses --p-spacing, the note's own gap between blocks.

Happy to reshape any of this - the placement question in particular is yours to call.

[callumalpass]

Thanks for the fix and detailed explanation. Merged into main—much appreciated!