Web: ScrollAdjust never removes its temporary padding-bottom (string comparison vs. CSS serialization)

[szado]

Version: 3.3.9 (also reproduced on 3.3.3), web build (react-native-web / Expo web), Chrome.

ScrollAdjust.tsx pads the content container to make room for a downward scroll adjustment and reverts it on the next animation frame, but only if the inline style still equals the string it wrote:

const temporaryPaddingEnd = `${(currentPaddingEnd || 0) + pad}px`;
temporaryPaddingRef.current = { baseline: baselinePaddingEnd, value: temporaryPaddingEnd };
contentNode.style[axis.paddingEndProp] = temporaryPaddingEnd;
// ...
requestAnimationFrame(() => {
  if (contentNode.style[axis.paddingEndProp] === temporaryPadding?.value) { // fails
    contentNode.style[axis.paddingEndProp] = temporaryPadding.baseline;
  }
});

(currentPaddingEnd || 0) + pad is an unrounded float, so the written string is e.g. "258.15000000000003px", while the browser stores and serializes it as "258.15px":

el.style.paddingBottom = '258.15000000000003px';
el.style.paddingBottom; // "258.15px"  -> the guard never matches

The padding therefore stays forever. The result is permanent empty scrollable space below the last item that the list itself knows nothing about (getContentSize() does not include it).

Repro: a vertical list with alignItemsAtEnd, maintainScrollAtEnd, maintainVisibleContentPosition: {data: true, size: true}, initialScrollAtEnd, mounted at the end; then let already-measured rows shrink (we simulate images whose real dimensions arrive ~2 s after mount). Intermittent - it only bites when the computed value does not round-trip through CSS serialization.

[chrisnojima]

Confirming this on 3.3.10 (current latest) in an unrelated Electron/Chrome app, and adding a
second way the guard fails that may matter for the fix.

A second route to the same mismatch. Alongside float noise (258.15000000000003px ->
258.15px), the comparison also fails for values that are simply too large to survive CSS length
serialization, which keeps ~6 significant figures:

const el = document.createElement('div');
el.style.paddingBottom = '27742.25px';
el.style.paddingBottom;  // "27742.2px"  -> guard fails
el.style.paddingBottom = '12345.678px';
el.style.paddingBottom;  // "12345.7px"  -> guard fails
el.style.paddingBottom = '258.15px';
el.style.paddingBottom;  // "258.15px"   -> round-trips fine

So the padding does not need excess float digits to strand; a clean fractional value large enough to
exceed six significant figures is enough. Every leak we captured ends in exactly one decimal place,
which is that truncation signature: 11522.2px in our app, 72730.2px / 72488.2px / 75155.8px
/ 71664.2px in a standalone repro. This makes it more likely in long lists, where the adjustment
distances are large.

Since pad is (nextScroll + viewportSize - totalSize) * 2 and layout tends to land on half
pixels, the doubling often yields whole numbers that round-trip fine, which is part of why it is
intermittent. Comparing against the value read back after writing (or tracking the intended padding
in a ref instead of the DOM string) would sidestep both routes.

Repro. https://github.com/chrisnojima/legend-list-scrolladjust-padding-leak — stock 3.3.10, no
patches: a list with alignItemsAtEnd, initialScrollAtEnd,
maintainScrollAtEnd, maintainVisibleContentPosition={{data: true}}, recycleItems, fractional
row heights, mounted at the end; then randomised large prepends/appends with the occasional
scrollToEnd. It leaked in 4 of 4 runs after 17, 18, 37 and 68 interactions:

*** LEAKED after 37 steps *** inline padding-bottom: 72730.2px | scroller can still scroll 72730px | list.isAtEnd: true

A different trigger from the shrinking-rows case in the report, so the underlying guard looks like
the common factor rather than any particular size change.

One note for anyone working around it downstream. Keying the detection on "the list reports
isAtEnd but the scroller still has slack" is not sufficient: the padding can be stranded while the
user is scrolled up, and by the time they scroll back down they are inside the phantom region with
no slack left to detect. Keying on the padding's own lifetime instead (anything still present two
frames after the write is stale) covers both.

Happy to test a fix against the repro and against our app.

Diagnosed with the help of Claude Code.

[chrisnojima]

We're shipping this as a patch-package workaround in the meantime, in case it is useful to anyone
else hitting it (or as a starting point for the real fix).

The ref records the string it is about to write, so the guard a frame later compares against a
value the browser may never have stored. Recording what the browser actually kept makes the
comparison like for like:

diff --git a/node_modules/@legendapp/list/react.mjs b/node_modules/@legendapp/list/react.mjs
@@ function ScrollAdjust() {
             const temporaryPaddingEnd = `${(currentPaddingEnd || 0) + pad}px`;
-            temporaryPaddingRef.current = { baseline: baselinePaddingEnd, value: temporaryPaddingEnd };
             contentNode.style[axis.paddingEndProp] = temporaryPaddingEnd;
+            temporaryPaddingRef.current = { baseline: baselinePaddingEnd, value: contentNode.style[axis.paddingEndProp] };
             void contentNode.offsetHeight;

(Same hunk in react.js, react-native.web.js and react-native.web.mjs.)

That covers both routes to the mismatch — the float noise in the original report and the
six-significant-figure truncation — without needing to know which values do or do not round-trip.
Rounding the written value would also close the float-noise route, but not the truncation one.

Verified against the repro linked above: it leaked in 17-68 interactions unpatched, and survived
four full hammer runs with this applied. Also clean across a 60-switch sweep in our app, with no
lingering padding.