[Bug]: iOS Link a machine sheet rubber-bands instead of scrolling (3.0.0 build 226) #35987
Send to my agent
Observed behavior
On iPhone, T3 Code 3.0.0 (226), the Link a machine sheet with a long machine list moves during an upward drag, then springs back when released. The Link and Cancel buttons cannot be reached reliably. No startup crashes were reported.
The supplied recording shows the expanded sheet header/grabber staying stationary while the content rubber-bands. The build's source commit and active OTA revision have not been established.
Reproduction
- Have an agent request a link without naming a target machine.
- Tap Choose machine…, with at least nine machines in the list.
- Expand the sheet, swipe upward, and release.
- Try tapping Link and Cancel without holding the content in place.
Expected: the content stays scrolled after release and the bottom actions are reachable.
Investigation
The link form uses the shared Sheet. #25828 changed its wrapper from flex-1 to absolute inset-0; that change is present on inspected main 99224f098d.
A native iOS 27.2 simulator comparison used the actual shared Sheet component with a temporary synthetic nine-machine form and the link form's scroll props:
- Reverting only that wrapper reproduced the failure: scroll frame and content were both 1,207 points tall. Repeated swipes sprang back and bottom actions remained inaccessible.
- Restoring current main bounded the frame to 812 points while content remained 1,207. The released offset remained at 348 points; Link and Cancel were both visible and tappable.
This is component-harness evidence, not full-app or build-226 verification. The installed simulator client lacks current main's GtReactNative module; rebuilding the matching native client failed with disk error errno 28. Available Expo access cannot read the owning project's build records. No product-code change or new PR was made because the inspected implementation already passes this bounded reproduction.
Remaining work
- Establish build 226's source/active OTA revision and whether it includes the existing sheet height constraint.
- Run the complete link form on a compatible current-main iOS build, with the same long list, both half-height and expanded.
- If it still fails, inspect native scroll frame/content sizes after detent changes and implement the smallest verified fix.
- Close only after the full form retains scroll position after release and both actions work.
tanstack-source added labelsbug
juliusmarminge closed this
Sign in to join this conversation.
I tried to reproduce this on the current build and could not.
Commit 43ce39595b (origin/main). Started an isolated dev server (T3CODE_DEV_SEED=0, fresh database, linkedEnvironmentsEnabled on) and Metro from that checkout. A Pi agent turn (Haiku 5.5) called t3_environment_link with only a hint, so the thread got a pending 'Choose machine…' card. Leased an iPhone 18 Pro (iOS 27.2) simulator from the device pool, installed the cached dev client with
vp run mobile:install iosand paired it. The app only lists paired machines and this run had one environment, so a local edit (not committed, reverted afterwards) to useLinkableMachines added nine synthetic machines; the real LinkRequestSheet and shared Sheet were unchanged. Steps: open the thread, tap Choose machine…, drag the grabber up to the 0.9 detent, do three upward flings inside the content, release. Result: the list scrolled to the bottom and stayed there; 'Another address…', Link and Cancel were visible and not held in place. Selecting Synthetic machine 9 made the form longer (pairing-code field, five access choices, note); two flings and a slow pan scrolled to Link and Cancel, the position held, Full access could be selected and Cancel closed the sheet. At the half detent, flings expanded the sheet and then scrolled to the bottom, where it stayed. No rubber-banding in any case.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.