You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(mobile): Android follow-up menu shows in full with the keyboard open - #29263
On Android, with the on-screen keyboard open, long-pressing the send button during a running turn opens the follow-up menu ("Steer now" / "Queue") as a ~38dp strip above the composer: only "Steer now" and its checkmark show, and the descriptions and the Queue row are cut off. With the keyboard dismissed the same menu renders in full. Reproduced on main (47f2c8d) on a Pixel 9 (Android 16, Gboard): start a turn (sleep 900), type a follow-up with the keyboard up, long-press send.
Change
Menus opened while the keyboard is visible render in-window (AndroidAnchoredMenu), in a wrapper that had a Reanimated entering={FadeIn.duration(120)} layout animation. The Compose host inside reports its intrinsic height only after the first layout; the entering animation keeps the wrapper at that first frame (sized only by the menu's React Native icon children), so the menu was clipped. The wrapper is now a plain View, so it follows the content's real height. Every Android menu opened with the keyboard up goes through this wrapper, so the same clipping also hit other menus on main (for example the thread filter, rows D and F below) and is fixed for them too. Menus opened with the keyboard open now appear without the 120 ms fade; the keyboard-closed native popup is unchanged.
No code changes; evidence and verification added below. This round recaptured the evidence against a fresh fixture matrix (8 checkpoints × Light/Dark), replacing the earlier capture notes.
Evidence
Real Android dev client (native fingerprint 971743703b, shared by both sides), each side from its own checkout, Metro and fresh server database (T3CODE_DEV_SEED=0), same driver. Pooled emulators, Android 16 / API 36, Gboard up at every open, system font scale 1.0, explicit T3 Code Light or Dark. Pixel 9: 1080×2424 px, density 2.625; Small Phone: 720×1280 px, density 2.0 (360×640 dp). Stills are full-device first-open frames (B Dark: third open) with a pixel-identical partner ≥1 s later; Diff0 marks any changed pixel, DiffT marks a channel delta >8/255 (A and B: >16/255). Each label links the before and after recordings of the same scripted open → dismiss → reopen → select flow.
A · Light · Pixel 9 · 16 pt (before, after) · before clipped on opens 1 and 3, Queue untappable; after full on all 3, Queue queues
A · Dark · Pixel 9 · 16 pt (before, after) · first open full on both (control); before clipped on open 3, Queue untappable; after full on all 3
B · Light · Small Phone 360 dp · 22 pt · Queue first (before, after) · full on all 5 opens on both sides (did not reproduce on before)
B · Dark · Small Phone 360 dp · 22 pt · Queue first (open 3) (before, after) · before clipped to Queue on open 3; after full on all 5, Steer now works
C · Light · Pixel 9 · 11 pt · attachment menu (before, after) · full on both; diff is 157 caret px
C · Dark · Pixel 9 · 11 pt · attachment menu (before, after) · full on both
D · Light · Pixel 9 · 16 pt · thread filter root (before, after) · before clipped to Environment on both opens; after shows Environment and Project
D · Dark · Pixel 9 · 16 pt · thread filter root (before, after) · before clipped on early opens (recording); settled stills identical
D1 · Light · Pixel 9 · 16 pt · Environment submenu (before, after) · full on both
D1 · Dark · Pixel 9 · 16 pt · Environment submenu (before, after) · full on both; 6 px nav-handle diff
E · Light · Pixel 9 · 16 pt · model filter root (before, after) · full on both
E · Dark · Pixel 9 · 16 pt · model filter root (before, after) · full on both
E1 · Light · Pixel 9 · 16 pt · Provider submenu (before, after) · full on both
E1 · Dark · Pixel 9 · 16 pt · Provider submenu (before, after) · full on both
F · Light · Pixel 9 · 16 pt · 13 projects, scrolled (before, after) · full on both; scroll and selection work
F · Dark · Pixel 9 · 16 pt · 13 projects, scrolled (before, after) · full on both; scroll and selection work
The clipping on main is intermittent (A Light opens 1 and 3, A Dark open 3, B Dark open 3, D Light every open, D Dark early opens; B Light never in five opens). The fixed build showed every menu in full on every scripted open.
What else changed (none of it from the PR): live provider text, conversation timestamps, the Working counter and feed position behind the A/B menus; caret blink (157–262 px) in some still pairs; 6 px in Android's navigation handle in D/D1 Dark; live status-bar clocks in recordings. With both menus rendered in full, menu content, order, palette and placement are unchanged. The 120 ms fade on keyboard-open menus is gone by design.
Row F independence: a fresh Metro plus cold launch matched the first after run at all 8 F geometry checkpoints (only caret pixels differ). D Light independence: a 79 px shift in an independent rebuild came from the emulator, not the app: android-04 has a 142 px cutout/status inset and android-03 has 63 px. With matching insets the cold rebuild is identical except 262 caret pixels.
Mode: evidence-only, head 3b020ab39b unchanged; merges cleanly with current main, which has not touched AndroidAnchoredMenu.tsx since the base.
Proof audit pass 1: fixture matrix derived from the code (Android, keyboard-visible-at-open branch only; iOS uses Menu.tsx/native MenuView and never renders this wrapper). Pass 2: 15/16 checkpoints sufficient; D Light independent rebuild differed by 79 px. Recaptured with recorded insets; cause found as above. Re-check of D Light: SUFFICIENT; all 16 checkpoints sufficient (pass 2 report, re-check report).
Tests: none added. The defect is native Compose measurement under a Reanimated entering animation, which a JS test cannot observe; the recordings are the proof.
CI on 3b020ab39b: Build and Typecheck (+14 checks), native fingerprint diff and agent context budget green; preview deploys skipped.
Unverified: Android versions other than 16, foldables/hinge placement, the exact timing of the removed fade. Frozen app clock and reduced-motion emulation are not available through the device tooling.
Lead: Claude Opus 5.5 in Claude Code via T3 Code; proof audit and captures: GPT-6.1 Sol in Codex via T3 Code.
Macroscope's review found this PR approvable — Removes the entrance fade from Android menus opened with the keyboard visible so their content can lay out fully. The change is presentation-only; menu actions and other menu behavior remain unchanged.
No code changes detected at 39f56ff. Prior analysis still applies.
You can add or adjust custom eligibility rules. Learn more.
Reviewing files that changed from the base of the PR and between 3b020ab and 39f56ff.
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
No actionable comments were generated in the recent review.
Walkthrough
The keyboard-visible Android menu now uses a regular View instead of Animated.View with a 120 ms FadeIn entering animation. The component no longer imports Animated or FadeIn.
Changes: Android menu rendering
Layer / File(s)
Summary
Replace the animated menu wrapper apps/mobile/src/components/ui/AndroidAnchoredMenu.tsx
The keyboard-visible menu uses a regular View instead of an Animated.View wrapper with a 120 ms FadeIn animation. The Animated and FadeIn imports were removed.
pingdotgg/t3code#29225: Both PRs change the animated wrapper for the Android follow-up menu when the keyboard is open.
Suggested labels:bugfix, size:XS
Suggested reviewers:maria-rcks
Merge Risk: Minimal · previous review 3b020
The Android menu change is ready to merge; the keyboard-visible wrapper preserves its existing layout and interaction behavior.
Pre-merge checks: 4
Check name
Status
Explanation
Title check
The title "fix(mobile): Android follow-up menu shows in full with the keyboard open" matches the main change. The PR replaces the Reanimated FadeIn wrapper in AndroidAnchoredMenu with a plain View, wh…
Linked Issues check
Issue [#29201] requires the Android Steer now / Queue menu to remain fully visible and usable while the keyboard is open. AndroidAnchoredMenu.tsx now uses a plain View for the keyboard-visible wra…
Out of Scope Changes check
The pull request changes only the keyboard-visible branch of AndroidAnchoredMenu.tsx. Removing the entering animation and replacing its wrapper with View directly supports the clipping fix. The sa…
Description check
The description is complete and follows the required structure. It clearly documents the Android clipping problem, reproduction steps, technical change, affected scope, linked issue, extensive before/…
Full details: Title check
Explanation
The title "fix(mobile): Android follow-up menu shows in full with the keyboard open" matches the main change. The PR replaces the Reanimated FadeIn wrapper in AndroidAnchoredMenu with a plain View, which fixes the clipped follow-up menu when the keyboard is visible. It follows conventional commit format and is specific. It is 72 characters, which is slightly long but within reason. The title does not mention that the fix also applies to other in-window Android menus, such as the thread filter. That is a secondary effect, so the title still passes.
Full details: Linked Issues check
Explanation
Issue [#29201] requires the Android Steer now / Queue menu to remain fully visible and usable while the keyboard is open. AndroidAnchoredMenu.tsx now uses a plain View for the keyboard-visible wrapper instead of the Reanimated FadeIn wrapper. The existing scrollable MenuPopup remains inside that wrapper, so the wrapper can follow the Compose host's reported height. The keyboard-closed MenuPopup path is unchanged. The reported Pixel 9/API 36 captures cover full menu visibility and selection for Steer now and Queue. The reported changed checks also pass.
Full details: Out of Scope Changes check
Explanation
The pull request changes only the keyboard-visible branch of AndroidAnchoredMenu.tsx. Removing the entering animation and replacing its wrapper with View directly supports the clipping fix. The same shared component also fixes other keyboard-visible in-window menus, which is a connected effect of the implementation. The keyboard-closed native popup remains unchanged. No unrelated repository changes are reported.
Full details: Description check
Explanation
The description is complete and follows the required structure. It clearly documents the Android clipping problem, reproduction steps, technical change, affected scope, linked issue, extensive before/after UI evidence, test results, limitations, and agent details. The scope section does not include an explicit maintainer approval comment, but the focused bug fix and linked issue provide sufficient context.
Finishing Touches
Generate docstrings
Commit to this branch
Create a new PR
Generate unit tests (beta)
Commit to this branch
Create a new PR
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
CodeRabbit Verify
Run CodeRabbit Verify to test the changes in this pull request.
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 7 remain after this review.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bugfixFix PR opened by an issue lead; enters the PR looppr:readyEvery gate passed; waits for Julius's land labelsize:XS0-9 changed lines (additions + deletions).vouch:trustedPR author is trusted by repo permissions or the VOUCHED list.
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
github-actions
Bot
added
vouch:trusted
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
juliusmarminge
added
bugfix
Problem
On Android, with the on-screen keyboard open, long-pressing the send button during a running turn opens the follow-up menu ("Steer now" / "Queue") as a ~38dp strip above the composer: only "Steer now" and its checkmark show, and the descriptions and the Queue row are cut off. With the keyboard dismissed the same menu renders in full. Reproduced on main (47f2c8d) on a Pixel 9 (Android 16, Gboard): start a turn (
sleep 900), type a follow-up with the keyboard up, long-press send.Change
Menus opened while the keyboard is visible render in-window (
AndroidAnchoredMenu), in a wrapper that had a Reanimatedentering={FadeIn.duration(120)}layout animation. The Compose host inside reports its intrinsic height only after the first layout; the entering animation keeps the wrapper at that first frame (sized only by the menu's React Native icon children), so the menu was clipped. The wrapper is now a plainView, so it follows the content's real height. Every Android menu opened with the keyboard up goes through this wrapper, so the same clipping also hit other menus on main (for example the thread filter, rows D and F below) and is fixed for them too. Menus opened with the keyboard open now appear without the 120 ms fade; the keyboard-closed native popup is unchanged.Scope and approval
Fixes #29201
Takeover
No code changes; evidence and verification added below. This round recaptured the evidence against a fresh fixture matrix (8 checkpoints × Light/Dark), replacing the earlier capture notes.
Evidence
Real Android dev client (native fingerprint
971743703b, shared by both sides), each side from its own checkout, Metro and fresh server database (T3CODE_DEV_SEED=0), same driver. Pooled emulators, Android 16 / API 36, Gboard up at every open, system font scale 1.0, explicit T3 Code Light or Dark. Pixel 9: 1080×2424 px, density 2.625; Small Phone: 720×1280 px, density 2.0 (360×640 dp). Stills are full-device first-open frames (B Dark: third open) with a pixel-identical partner ≥1 s later; Diff0 marks any changed pixel, DiffT marks a channel delta >8/255 (A and B: >16/255). Each label links the before and after recordings of the same scripted open → dismiss → reopen → select flow.47f2c8d29e
3b020ab39b
47f2c8d29e→3b020ab39b
47f2c8d29e→3b020ab39b
The clipping on main is intermittent (A Light opens 1 and 3, A Dark open 3, B Dark open 3, D Light every open, D Dark early opens; B Light never in five opens). The fixed build showed every menu in full on every scripted open.
What else changed (none of it from the PR): live provider text, conversation timestamps, the Working counter and feed position behind the A/B menus; caret blink (157–262 px) in some still pairs; 6 px in Android's navigation handle in D/D1 Dark; live status-bar clocks in recordings. With both menus rendered in full, menu content, order, palette and placement are unchanged. The 120 ms fade on keyboard-open menus is gone by design.
Row F independence: a fresh Metro plus cold launch matched the first after run at all 8 F geometry checkpoints (only caret pixels differ). D Light independence: a 79 px shift in an independent rebuild came from the emulator, not the app: android-04 has a 142 px cutout/status inset and android-03 has 63 px. With matching insets the cold rebuild is identical except 262 caret pixels.
Full step logs, timestamps, all sheets and diffs: evidence index · fixture matrix · scripts (uploaded, synthetic data only): A/B driver, A/B seed, project seed, C–F scripts, D Light scripts, A/B rebuild steps.
Verification log
AndroidAnchoredMenu.tsxsince the base.Menu.tsx/nativeMenuViewand never renders this wrapper). Pass 2: 15/16 checkpoints sufficient; D Light independent rebuild differed by 79 px. Recaptured with recorded insets; cause found as above. Re-check of D Light: SUFFICIENT; all 16 checkpoints sufficient (pass 2 report, re-check report).🤖 Generated with Claude Code