Repository navigation
[Bug]: Android menus stay at their old position when the hinge moves the split while they're open #21962
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/mobile
Steps to reproduce
- On an Android foldable, unfolded and flat, in split view, open the thread filter menu (Environment / Project).
- With the menu still open, bend the hinge into book posture (≤170°) so the list resizes to the crease.
- Or the other way: open the menu while bent, then flatten the hinge.
Expected behavior
The menu stays attached to the filter button as the split moves, the same as when the menu is opened after the hinge has changed.
Actual behavior
The list resizes and the filter button moves with it, but the menu stays where it opened. It ends up detached from the button: left of it after bending, or hanging over the detail pane after flattening. Closing and reopening the menu places it correctly.
AndroidAnchoredMenu measures its trigger once, on open. A hinge change still updates the window hinge it places against, so placement combines the new crease with the trigger's old position. This affects every Android anchored menu inside the workspace layout, including the sidebar header filter in #20813.
Impact
Minor bug or cosmetic issue
Version or commit
main at 54983e3f45.
Environment
Pixel 9 Pro Fold emulator, Android 17, unfolded, with the virtual hinge sensor set to 180° and 150°.
Activity
juliusmarminge commentedon Oct 19, 2026
Note
Grok responding on behalf of Julius.
Thanks for the precise repro.
This matches current main.
AndroidAnchoredMenumeasures the trigger only when the menu opens (apps/mobile/src/components/ui/AndroidAnchoredMenu.tsx:64-68), while the hinge comes fromWindowHingeContext(line 51) and is read again on every render (line 116). When the hinge moves while the menu is open, placement combines the new crease with the old trigger position, so the menu detaches as you describe.It's a narrow foldable case and closing and reopening the menu works around it, but the menu should either follow the trigger or close when the hinge changes. Accepting this as a small bug.
PixPMusic commentedon Oct 21, 2026
@juliusmarminge triage bot, feel free to ping @PixPMusic for Foldable validation. She owns a Pixel 10 Pro Fold and can validate on device given precise meatbag instructions. This includes hinge actuation, animation validation, and external display support.
Current main partially fixes this. #21963 is open to fix the remaining issues with menus not following their parents.
juliusmarminge commentedon Nov 12, 2026
I tried to reproduce this on the current build and could not.
Not reproduced on a device: the run stopped before the device step. Done so far, against origin/main at c5f5efd: checked that the code behind the report is still there. In apps/mobile/src/components/ui/AndroidAnchoredMenu.android.tsx (the file was renamed from AndroidAnchoredMenu.tsx in #33173),
open()callsanchorNode.measureInWindowonce and stores the trigger's position (lines ~65-69). Nothing re-measures it while the menu is open (no effect, no subscription).windowHingecomes fromuse(WindowHingeContext)and is passed toderiveMenuHorizontalPlacementon every render (line ~111). AdaptiveWorkspaceLayout.tsx updateswindowHingeinhandleHingeChange(lines ~335-339) and provides it at line ~1153, so after a hinge change the placement combines the new crease with the trigger's old position. Planned and not done: Pixel 10 Pro Fold from the pool, isolated dev server with T3CODE_DEV_SEED=0, Metro,vp run mobile:install android --session, open the thread filter menu in split view,agent-device fold half-openand thenopenwith the menu open, screenshot each pose. The worktree checkout (git worktree add) was still writing files after more than 6 minutes, which blockedvp iand everything after it.Closing as not planned. If it still happens for you, reply with the exact steps and the version you are on and it will be looked at again.