fix(mobile): approval card buttons line up#31415

External image Major · Functional Correctness · Heavy lift

Count child approval height in the iOS approval cap.

On iOS, ComposerPanels is an Animated.View with no height limit. The approval maxHeight (approvalHeightStyle) uses only the window, keyboard, header, and composer heights. ChildThreadApprovals renders above the active approval in the same stack and can use up to min(320, maxHeight / 2). The two caps do not sum to the available space. A tall approval with a child approval can extend above the header. The child's scroll view can then sit outside the reachable area.

Include the child approval height in the approval cap, or make the complete iOS panel stack scroll within a bounded container, as Android does.

Out of scope here. A child approval and a tall parent approval stacked together on iOS could already overflow before this PR, when the parent card had no cap at all. This change narrows it. Bounding the whole iOS ComposerPanels stack is a separate layout change: on iOS that stack is deliberately a plain view so question cards can overlay the controls. It belongs in its own PR.

@shivamhwp You're right. I treated a pre-existing stack overflow as a defect introduced by this PR. The new cap limits the parent approval; it does not need to solve the full iOS panel-stack layout.

I withdraw this finding for this PR. A separate layout change must preserve the iOS question-card overlay behavior.

Would you like me to open a follow-up issue for the combined child-and-parent approval overflow?

Review thread resolved.

_{You are interacting with an AI system.}

External image Minor · Functional Correctness · Quick win

Do not apply the question card’s minimum height here.

derivePendingUserInputMaxHeight has a 160-point floor, even when less space remains above the composer and keyboard. On a short screen or with an expanded composer, the approval viewport extends above the header, so its first content cannot be brought into view. Cap the viewport to the actual available height. (raw.githubusercontent.com)

Keeping the floor. It is the same 160-point minimum the question card uses in the same spot, and it only applies when less than 160 points remain above the composer and keyboard. Below that, a smaller viewport would not show a usable card either. Before this PR the approval card had no cap at all, so this only narrows the case where it can reach the header.

@shivamhwp Understood. Keeping the 160-point floor is an intentional usability tradeoff, consistent with the question card. The new cap still improves the previously uncapped approval card. I withdraw the request to remove the floor.

Review thread resolved.

_{You are interacting with an AI system.}

External image Minor · Functional Correctness · Quick win

Reset the scroll position for each approval.

When the first pending approval is replaced directly by another approval, the unkeyed Animated.ScrollView can retain its previous offset. The next approval can show its buttons while its request details remain above the viewport.

Key the scroll view by requestId.

✅ Addressed in commit f679021

Fixed in f679021c1c: the scroll view is keyed by requestId, so a replacement approval starts at the top.

@shivamhwp Thanks. The supplied code includes key={props.activePendingApproval.requestId}, which remounts the scroll view when the approval changes and resets its scroll position.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

Review thread resolved.

_{You are interacting with an AI system.}