Repository navigation
[Bug]: Android new-thread composer toolbar (+ / model / send) invisible when "Remove animations" is on #16080
Description
Activity
Note
Grok responding on behalf of Julius.
Triage
Thanks @LukasOnAir. The report matches current
main(1a3f7ad). This is a mobile client bug, which is why the server trace stays clean. It is not a duplicate of #15953 or #16015. Those are programmatic scrolls that still animate under Reduce Motion. Here a control that should appear instantly never does.What I found
The new-thread toolbar is mounted immediately, already inside an entering animation that starts hidden.
NewTaskDraftScreenrendersComposerDictationToolbarwith the screen. It does not passvisible, so the animated row is created on first paint.- That row uses
entering={toolbarFlip(90, 0)}inComposerDictationControl.tsx. The initial pose isopacity: 0androtateX: 90deg, withbackfaceVisibility: "hidden". The prompt editor is a sibling, so the card still looks like a composer while +, the model picker, and send are invisible. withTimingis already set toreduceMotion: ReduceMotion.System. Android’s Accessibility “Remove animations” sets the animator duration scale to 0, which React Native reports as reduced motion, so this flip finishes on its first frame instead of playing out.- Reanimated 4.7 (what
apps/mobilepins) inserts an entering view at opacity 0 and waits for a later animation frame to show it. On Android that first frame is dropped if the view is not mounted yet (software-mansion/react-native-reanimated#7493). A normal-duration flip still has later frames. A reduced-motion flip does not, and because the animation style includes opacity, the proxy’s opacity restore is cleared too. The row stays at the hidden pose. - An existing thread only mounts this same view once the composer is focused (
visible={isToolbarVisible}inThreadComposer.tsx), after the screen is already up. That later mount is why the toolbar can still appear there.
Likely fix area
ComposerDictationToolbarinapps/mobile/src/features/voice-input/ComposerDictationControl.tsx. When reduced motion is on, skip this entering animation and mount the toolbar in its resting style (opacity: 1, no rotation), instead of depending on a one-frame entering animation Android can drop. ThereduceMotionflag already onwithTimingdoes not do that. The same component is used by the scheduled-task prompt, so a fix there covers that screen too.A maintainer will decide on the fix direction.
Before submitting
Area
apps/mobile
Steps to reproduce
Expected behavior
The composer shows its toolbar: the attachment (+) button, the model / reasoning picker and the send button, the same as with animations on.
Actual behavior
The composer surface renders at full height with the prompt editor, but the toolbar row is invisible: there is no +, no model picker and no send button, so you can't start a thread from the app. Existing threads are not affected (their toolbar appears when you focus the composer). Turning "Remove animations" off and restarting the app brings the toolbar back.
Impact
Blocks work completely
Version or commit
Android app from the Play Store, installed 2026-10-05. Server 0.0.43-nightly.20260928.2375. Code read at main @ 1a3f7ad.
Environment
OnePlus Nord 3 5G (OxygenOS), Android, environment paired over Tailscale.
Logs or stack traces
Screenshots, recordings, or supporting files
No response
Workaround
Turn off Android's "Remove animations" and restart the app.
Likely cause (from reading the source)
ComposerDictationToolbar(apps/mobile/src/features/voice-input/ComposerDictationControl.tsx) wraps the toolbar in anAnimated.Viewwith a customenteringanimation (toolbarFlip(90, 0)) whose initial values areopacity: 0androtateX: 90deg. On the new-thread screen (NewTaskDraftScreen.tsx) the toolbar mounts together with the screen, and with system reduced motion the entering animation seems to never move it to its final state, so it stays transparent / edge-on. InThreadComposer.tsxthe toolbar only mounts later (visible={isToolbarVisible}once the composer is focused), which may be why existing threads are fine. Possible fixes: setreduceMotionon the layout animation so it jumps to the end values, or skip the entering animation on initial mount.