fix: scroll until through virtualized content - #4407

Size Report

Startup median (7 runs, lower is better):

Apex Sentinel

Verdict: approve

Since the last review: 1 new · 1 still open · 1 no longer raised (1 marked fixed)

2 finding(s): 2 minor.

🟡 Minor (2)

2 findings below minor not shown (user_settings.min_severity).

Reviewed with this repository's own Sentinel configuration (eb4fede2343e).

Feedback goes in the review comment threads, as a reply under the inline comment of a finding:

Reply @apex-sentinel-staging note ... to add context, or @apex-sentinel-staging pivot ... if it is wrong — I will re-check the cited code.

Useful? Reply @apex-sentinel-staging like, or @apex-sentinel-staging dislike <why> if it is not.

Comment @apex-sentinel-staging review on this conversation to run a full review.

Earlier reviews

The code in ea51273 is ready to merge. All 19 checks pass and there are no conflicts. Not blocking, and you can take or leave these: reuse scrollNoProgressHint() in scroll-until.ts through an option for the "may have ended" lead-in, instead of an inline copy of its text; drop the value === 'collection' arm in snapshot-scroll.ts unless a producer emits that raw type (iOS emits CollectionView, which already matched); document in help and docs that --until confirms an end by gesturing until the content stops moving, because scroll-until.ts no longer reads canScroll, so a list at its edge now sends several drags that could trigger pull-to-refresh or dismiss a sheet; update the three stale doc comments near selection.ts to say only scroll top/bottom trust canScroll; file a follow-up so scroll bottom in scroll-edge-state.ts uses the same movement rule as --until; and, if you can, run scroll down --until 'id="row-999"' --max-passes 20 on the List and sheet repros at head and show scroll_until_edge_reached with fewer than 20 passes. Whether a resting SwiftUI List gives byte-identical consecutive captures is not verified, and that decides between scroll_until_edge_reached and pass_limit. The iOS 27 run at head is your claim with no transcript, the sheet and LazyVStack runs were on an earlier build, and iOS 26.5 was not run. I did not run tests locally.

Of the earlier review threads, the rubber-band edge_reached thread (#4407 (comment)) and the containerRect thread (#4407 (comment)) do not apply, because both only change the failure reason and never report success or end early. The no-container stall check (#4407 (comment)) and the pass/passes pluralization (#4407 (comment)) are fixed at head, so you can resolve all four.