Scroll Anchoring Priority Candidate Fix

concepts

1. Anchor Fix

   Chromes existing scroll anchoring now prefers earlier in-viewport candidates over later ones when picking the anchor element. Layout shifts caused by upstream insertions become less disruptive.

2. Contenteditable Drift

   The motivating case: a large focused contenteditable used to absorb the anchor, dragging the caret offscreen on upstream inserts. v139 anchors the deepest onscreen descendant instead. Live demo with caret-drift measurement.

3. Find-in-Page Stability

   Highlight a find-in-page match in a long article, then stream in layout shifts above it — images, banners, paragraphs. The status pill tells you whether the scroll anchor stayed on the highlight (v139 fix) or drifted off (pre-v139).

4. Layout Shift & Scroll Anchor Debugger

   Two side-by-side articles — left with overflow-anchor: none (pre-v139), right with overflow-anchor: auto (v139). Three injection scenarios — late image, ad insertion, content expansion — let you see the scroll position jump vs stay stable, with a CLS score and timestamped jump log for each column.

why it shipped

Currently, scroll anchoring algorithm selects priority candidates when they are available as anchor targets. The priority candidates are currently a focused editable element and find-in-page highlights. This can cause suboptimal user experience if there is a large focused contenteditable element that has content changed offscreen (the

references

• ChromeStatus entry