fix(mobile): pulling to Load earlier activity no longer snaps the feed back to the end#31907

Problem

In a thread whose loaded page is about one screen tall, pulling down to "Load earlier activity" and releasing turns end-following back on. The next layout or data change then scrolls the feed back to the end, the button goes back under the header, and older history can't be reached.

Reproduced on current main in an iPhone 17 Pro simulator: a running agent turn with a 75-row first page (contentSize 826–967 pt, viewport 874 pt, header inset 116 pt, composer inset 142–255 pt). After release at the top, the list reported isAtEnd: true at scroll −116 (no jump-to-end arrow). Tapping "Load earlier activity" then jumped the feed to the absolute end.

Change

getIsAtEnd in our @legendapp/list@3.3.5 patch had two errors:

• Its at-end distance subtracted the end (composer) inset, but getContentSize already includes that inset. Any position within about one composer height of the end therefore counted as the end. On a feed about one screen tall, that covers the whole scroll range, including the top. Legend List 3.7.1 already uses contentSize - scroll - scrollLength for this distance.
• Its "content fits" shortcut (contentSize < scrollLength) ignored the start inset that the patch adds for the transparent header.

The function now uses one rule for every list. Content fits when contentSize - scrollLength <= -contentInsetStartAdjustment (+1 pt). Otherwise the list is at its end only within 1 pt of its real end. Both the react-native.js and react-native.mjs hunks change; nothing else in the patch does.

What changes for users: following re-arms only when you return to the real end. A release that stops a little short of the end, or a disclosure that grows the content while following, now leaves following off and shows the jump-to-end arrow. ThreadFeed's comment already called for this ("Re-arm follow only at the actual end").

Scope and approval

Fixes pingdotgg/t3code#31867

Verification

• apps/mobile/src/features/threads/legendListAtEnd.test.ts loads the installed patched bundle in node:vm and calls getIsAtEnd with geometry measured on the simulator. On main it fails with a feed pulled to its start edge (scroll -116) is 77.8pt from its end: expected true to be false. It covers:

  • a feed pulled to its start edge (scroll −116);
  • a feed 2 pt below the start edge (scroll −114);
  • a feed under an opaque header with no start inset (rows 700, composer inset 200, scroll 0);
  • control cases that must still read at end: the real end, and content that fits below the header.

  All of these pass with the fix, and thread-feed-live-follow.test.ts still passes.

• vp run check:changed passes: unused patches, format, lint, knip, typecheck for 40 packages, and tests.

• Simulator runtime transcript (iPhone 17 Pro, dev client against an isolated dev server with a synthetic thread). Each row is the isAtEnd reading from temporary logging in the installed bundle, plus the behaviour seen:

  Build	contentSize	Scroll	isAtEnd	Seen after release, then tapping "Load earlier activity"
  main	835.8	−116 (start)	true	no jump-to-end arrow; the load lands at the end
  main	938.8	−116 (start)	true	no jump-to-end arrow; the tap jumps to the absolute end (scroll 92.7)
  first draft of this fix	826.4	−116 (start)	false	arrow shown; the position stays put
  first draft of this fix	966.8	−116 (start)	false	arrow shown; the position stays put
  this PR	826.8	−47.3 (end, on open)	true	—
  this PR	~940	release at the top	— (log not captured)	arrow shown; older rows load above and the position is kept

  Android (Pixel 9 emulator, no start inset): a thread that fits the screen opens with the button visible and reads at end (true).

• Not checked: before/after recordings are not attached. The iOS 18 opaque-header path is covered by the test above, not on a device. Keyboard open and close while following were not exercised on a device.

AI-assisted; verified with the tests and tools listed above.