fix(scroll-sync): measure a block from the scroll container, not from its offset parent

[PathGao]

Follows #474, on @Guardiancelte's retest of it: the per-block mapping is right, the ruler it reads is not.

offsetTop is not the distance to the top of the document

The mapping resolves a position by descending to the annotated element that owns it and reading offsetTop. That is measured from the element's offset parent, which CSSOM defines as the nearest positioned ancestor — or the nearest table, td or th, positioned or not. #474 assumed one offset parent for everything in the preview and said so in a comment. The preview has plenty.

Measured in Chrome, over this app's own styles.css:

element                        offsetTop   offsetParent          really at
p                                     84   article.markdown-body        84
table                                994   article.markdown-body       994
tr   (a row of that table)             1   TABLE                       995
td                                    32   TABLE                      1026
tr   (the last row)                   94   TABLE                      1088
pre  (a code block)                    0   div.code-block-shell       1135

comrak stamps a source range on every table row and cell, so the descent goes inside a table and reads that middle column as if it were the right-hand one. renderRichContent wraps every code block in a position: relative shell for the copy button, so a code block reports 0.

Both of @Guardiancelte's cases are that, from the two directions:

• line → offset. A line inside a table resolves to ~200px, so the pane scrolls to the top of the document. "one scroll down, it sends me to the top of the document, and it never comes back until I am passed both tables".
• offset → line. Every row's box is far above an offset in document space, so the nearest row is always the last one: the other pane freezes on the end of the table until the reader is past it, then jumps. "the left side is frozen until the top of the table is visible on the right side… and when that unfreeze, one scroll down shot the left side all the way back down".

The direction that misbehaves depends on which pane is sending, which is why it looked like the mouse side mattered.

The fix

measureAnchorBox sums the offset-parent chain and subtracts the container's own sum. Subtracting rather than stopping at the container is what keeps it exact whether or not the container is itself an offset parent — with .markdown-body's transform: translate3d(0,0,0) Chrome makes it one, but nothing should depend on that.

The tab-restore path and the front-matter carve-out read the same measurement now; both used raw offsetTop and had the same defect (an anchor saved inside a table reopened the tab at the top).

Mermaid — the other half of the report

preEl.replaceWith(container) gave the diagram none of the code block's data-sourcepos, and Mermaid's SVG keeps nothing of the <pre> either, so a diagram was the one block in the preview that mapped to no source line at all — not even through a descendant. Several hundred pixels of preview got attributed to whatever block was nearest, which is why the two panes' top headings disagreed by about a diagram (# 11. Mermaid Diagrams against Sequence Diagram). The container now inherits the range it replaced.

Cost

Two to three extra offsetTop reads per candidate. Measuring every annotated element of a 9,900-element preview in Chrome: 2.20 ms read raw, 6.30 ms walked. A descent measures a few dozen, so this is tens of microseconds on a scroll event, against the 0.89 ms the descent itself costs on a 13,356-line document.

Tests

scripts/scrollSyncBlockMapping.test.ts had the blind spot in the shape of its own layout: layOut handed the mapping one flat stack of absolute tops, which models a preview containing neither a table nor a positioned wrapper. Same class of miss as #464 — the shim has no layout, so what it does not model cannot fail.

It now models the offset parent instead. Every box is converted to what a browser would report before the production measureAnchorBox converts it back, the fixture's tables carry the row and cell ranges comrak really emits, and wrapCodeBlocks puts the .code-block-shell around the <pre>s the way renderRichContent does. rawMeasure — offsetTop read raw — is kept alongside as the control, the way RATIO_ONLY is.

Falsification, mapping reverted to raw offsetTop, tests kept:

✖ the tail of the document stays on the same source line
  AssertionError: the preview drifted 622.8 source lines from the editor at scrollTop 11834 (of 12158)
✖ every part of the document stays on the same source line, not only the tail
  AssertionError: the preview drifted 623.9 source lines at scrollTop 11854
✖ scrolling one pane down always moves the other pane down
  AssertionError: editor 6930 -> 6991 moved the preview backwards: 9576.0 -> 34.0
✖ a line inside a table maps into that table, not to the top of the document
  AssertionError: a line in a table at 20184px resolved to 204px
✖ an offset inside a table resolves to the row at it, not to the row after the last
  AssertionError: halfway down the table resolved to line 670 of 655-670
✖ a row reports an offset measured from its table, and a code block from its shell
✖ an echo through the other pane settles in one step
✖ touching blocks do not walk the panes up the document
ℹ pass 14   ℹ fail 8

That third one is the reporter's screenshots exactly: one scroll click down, and the other pane at 34px.

And with only the Mermaid line reverted:

✖ a rendered diagram answers for the source lines it replaced
  AssertionError: flowchart: the diagram container must carry the source range of the code block it replaced

Verification

npm run check (0 errors), npm test (782 passing), cargo test (125 passing). npm audit reports one moderate advisory in mermaid 11.16.0, unrelated to this change and present on master.

What is still modelled rather than measured is the layout — whether a browser lays a table out the way the fixture's heights say. What is now measured is the thing that broke: the numbers in the table at the top of this description are from Chrome, not from the shim.

---

@Guardiancelte — thank you, both of those cases were real and neither was the mapping I described to you; they were the measurement under it. Your large-table file is the one I would most like retested once this lands. The remaining difference you may still notice is the one named in #474: what the panes align is the line at the top of each viewport, so at the very end of a document the preview is not necessarily at its own last pixel.