Fix mobile legend anchor under automatic iOS insets

[juliusmarminge]

Summary

• Adjust the thread feed anchor offset on iOS when automatic content insets are enabled.
• Fold the header height into the anchor math so newly sent messages do not anchor beneath the header.
• Keep maintainScrollAtEnd from snapping to the wrong position when UIKit-managed insets are in play.

Testing

• Not run (PR summary only; no local verification requested).
• Existing change is limited to apps/mobile/src/features/threads/ThreadFeed.tsx anchor calculations.

---

Note

Low Risk
Single-path change to anchor offset calculation in ThreadFeed; scroll UX only, no auth or data handling.

Overview
On iOS when usesAutomaticContentInsets is enabled, the thread feed now feeds anchorTopInset (safe area top + 44) into resolveChatListAnchoredEndSpace instead of topContentInset.

LegendList’s anchoring runs in JS and measures from the scroll view frame top, so it does not account for the header space UIKit puts in adjustedContentInset. Folding that header height into anchorOffset keeps newly sent messages from sitting under the transparent header and stops maintainScrollAtEnd from snapping to the wrong position due to oversized end space.

^{Reviewed by Cursor Bugbot for commit 5b66a6e. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix mobile legend anchor offset when using automatic iOS insets in ThreadFeed

When usesAutomaticContentInsets is true on iOS, UIKit adjusts the scroll view's content inset automatically, so topContentInset no longer reflects the true top offset used for anchoring. A new anchorTopInset value derived from insets.top + 44 is used instead, correcting the anchor position computed by resolveChatListAnchoredEndSpace. Behavior is unchanged when automatic insets are not in use.

📊 Macroscope summarized 5b66a6e. 1 file reviewed, 0 issues evaluated, 0 issues filtered, 0 comments posted

🗂️ Filtered Issues

No issues evaluated.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 76731ca6-29a6-4faf-9d0e-4ff6e9286d3b

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch t3code/fix-mobile-legend-anchor

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

🟡 Medium threads/ThreadFeed.tsx:1186

anchorTopInset hard-codes the iOS header height as insets.top + 44, but the actual React Navigation native header height varies by device and orientation (e.g. iPad defaults are taller than 44 pt). On those devices the computed anchoredEndSpace is too small, so a newly sent anchored message can remain partially under the header and maintainScrollAtEnd keeps snapping to the wrong position — the same regression this PR intends to fix. Consider using useHeaderHeight() from @react-navigation/elements instead of the hardcoded 44.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/mobile/src/features/threads/ThreadFeed.tsx around line 1186:

`anchorTopInset` hard-codes the iOS header height as `insets.top + 44`, but the actual React Navigation native header height varies by device and orientation (e.g. iPad defaults are taller than 44 pt). On those devices the computed `anchoredEndSpace` is too small, so a newly sent anchored message can remain partially under the header and `maintainScrollAtEnd` keeps snapping to the wrong position — the same regression this PR intends to fix. Consider using `useHeaderHeight()` from `@react-navigation/elements` instead of the hardcoded `44`.

[macroscopeapp]

Approvability

Verdict: Needs human review

1 blocking correctness issue found. This bug fix has an unresolved review comment identifying that the hardcoded header height of 44 may not work correctly on iPad or in different orientations, potentially causing the same regression the PR intends to fix. A human should evaluate whether to use useHeaderHeight() instead.

^{You can customize Macroscope's approvability policy. Learn more.}