0.5.208: on phone viewports the YOU step overflows and /scroll returns 200 without moving it (Android + iOS)

[emooreatx]

0.5.208: on phone viewports the YOU step is taller than the screen and /scroll returns 200 without moving it

0.5.208's band fix works on mobile — this is the next thing behind it, not a regression. Both Android and iOS now expose all three bands, where 0.5.206 exposed none on Android and only age_band_declined on iOS. bb76e51 reached every platform.

What blocks both mobile targets now is that the rest of the YOU step cannot be reached.

Evidence

Run #34147279506, 0.5.208, both mobile legs:

android  [FAIL] you_step: Input 'input_username' failed after scrolling:
         input_username is composed but off screen;
         on screen and drivable now:
           [age_band_adult, age_band_declined, age_band_minor, btn_next]

ios      [FAIL] you_step: Input 'input_username' failed after scrolling:
         input_username is composed but off screen;
         on screen and drivable now:
           [age_band_adult, age_band_declined, age_band_minor, btn_next,
            opt_run_with_ai, opt_run_without_ai]

Both desktop legs pass the same step in ~1.3s, so this is viewport height, not a layout fault: input_username, input_fedid_label and (on Android) both AI options are composed but off screen, and the visible window is the age row plus Next.

/scroll is present and answers 200, and nothing moves

This is the part worth your attention. 90ad6f3e9 added the Android route and I confirmed it in the shipped artifact — extracting route strings from each classes.jar:

0.5.206 aar:  /click /health /input /screen /tree /undrivable /wait
0.5.208 aar:  /click /health /input /screen /scroll /tree /undrivable /wait

So the 404s we saw on 0.5.206 are gone. There is not one scroll refused line anywhere in the 0.5.208 Android leg — our harness prints that only on a non-200, per the refusal contract you shipped in 0.5.207. The scrolls are being accepted and are not bringing the element on screen.

We try both directions (six attempts, 300px, down then up), so "we scrolled the wrong way past it" is ruled out. The two readings we cannot separate from outside:

1. /scroll resolves to a scrollable ancestor that is not the one the setup form actually scrolls in, so it scrolls a container with no overflow and truthfully reports success; or
2. the form is not in a scrollable container at all on mobile, and the overflow is simply clipped — in which case a human on a phone cannot reach the username field either, and this is a user-facing bug rather than an automation one.

We cannot tell those apart through the HTTP surface, and the difference matters a great deal: (2) means the mobile wizard is unusable, (1) means only our gate is blocked. A screenshot of the Android YOU step at emulator height would probably settle it in seconds on your side — shots/android.png in our artifact is captured after the failure if that helps.

What would make this self-evident from outside

Not a request, a suggestion, and only if it is cheap: if a 200 from /scroll reported what it actually did — the resolved scrollable's id, and the offset before/after — then "accepted but nothing moved" would be visible in the response rather than inferred from a later failure. The 0.5.207 refusal contract already made refusals legible; this is the same idea for the success path. Today a 200 that moved nothing and a 200 that scrolled correctly are byte-identical to us.

Status of the rest, for context

leg	no-AI	with-AI
windows	6/7, blocked on #43	separate port bug, ours, fixed
linux	6/7, blocked on #43	green, live model response
macos	6/7, blocked on #43	green, live model response
android	blocked here	blocked here
ios	blocked here	blocked here

The desktop with-AI path is fully green on 0.5.208 end to end, including a real answer on screen. Mobile is blocked at this step, and both mobile legs are blocked at only this step.

[emooreatx]

Your reading (2) is ruled out: the mobile wizard is usable. A person on a phone can scroll to the username field. Fixed on main at 4170176 — and your suggestion was the right one, so I built it.

Answering the question you couldn't answer from outside

YouStep wraps its content in a scroll container, in common code, on every platform:

val scrollState = rememberTestableScrollState()
Box(modifier = modifier.fillMaxSize()) {
    Column(
        modifier = Modifier.fillMaxSize().padding(24.dp).verticalScroll(scrollState)
    ) { … AgeRangeSection … AccountSection … FederationIdentitySection … }
    VerticalScrollbar(scrollState = scrollState, …)   // draws on desktop, no-op on mobile
}

and its parent gives it a bounded height (Box(Modifier.weight(1f)) inside a fillMaxSize Column), so the overflow is real and finger-scrollable. Only the scrollbar is desktop-only; the scrolling is not. So this is (1) — a /scroll reaching the wrong container — and no user is stuck.

Your evidence had already narrowed it further than the issue claims: the absence of any scroll refused line proves a consumer ran and cleared the request. Under the 0.5.207 contract a request nothing consumes times out and refuses. So something took the scroll, animated, and reported success — it just wasn't the container holding the form.

What was wrong, and it is the dispatcher, not the reporting

/scroll dispatched to the most recently composed scrollable. That is fine when one thing scrolls, and wrong the moment anything else registers later — a scaffold, a drawer, a sibling that happens to scroll. The newest container swallowed the request, had nothing to move, and truthfully answered 200.

Two changes:

• Dispatch now goes to the most recent scrollable that can actually move, falling back to the newest when none has overflow. It picks the right container without needing to know the layout tree.
• A 200 now means the screen moved. The consumer records before/after/max; unchanged offsets are a refusal naming why — has NO overflow (maxValue=0), already at the top, already at the bottom (900 of 900) — and a success carries the offsets:

success: true   text: "down:300 moved 0→300 of 1400"
success: false  error: "the scrollable on screen 'Setup' has NO overflow (maxValue=0),
                        so this is not the container holding what you are looking for;
                        on screen and drivable now: [age_band_adult, …]"

That is exactly what you asked for, and it is more than instrumentation: had it existed, your run would have said moved 0→0 of 0 on the first attempt instead of costing you a cycle to infer.

One thing to keep as-is

Your six attempts at 300px down-then-up stay correct, but note the response now tells you when to stop: already at the bottom means more scrolling cannot help, and NO overflow means you are talking to the wrong container. Retrying past either is wasted.

681 shared tests green; desktop and Android targets compile. Not in a published version yet — say the word and I will cut it, or I can fold it into the next release with anything else that lands. #43 is still yours as far as I know; tell me if any part of it is ours.

[emooreatx]

Preview build with the /scroll dispatcher fix is up — Android AAR included, no four-hour wait.

https://github.com/CIRISAI/CIRISClient/releases/tag/preview-scroll-dispatch

0.5.208+preview.g7058419 — that is 0.5.208 plus 4170176 (the dispatcher fix and the movement-reporting contract). Assets: the Android AAR, Linux and Windows desktop wheels, the universal wheel, the wasm wheel, and the localization bundle.

pip install https://github.com/CIRISAI/CIRISClient/releases/download/preview-scroll-dispatch/ciris_client-0.5.208%2Bpreview.g7058419-py3-none-manylinux_2_17_x86_64.whl

No macOS and no iOS — that is the trade that makes it ~30 minutes instead of four hours, so this answers the Android question only. It is a prerelease and the version carries a PEP 440 local segment, which PyPI refuses by design, so it can never be confused with a release.

What to expect on the Android leg:

• /scroll now dispatches to the most recent scrollable that can actually move, rather than whatever composed last. That is the defect: a container with no overflow was swallowing the request, not moving, and truthfully reporting success.
• A 200 now means the screen moved, and carries the offsets: down:300 moved 0→300 of 1400.
• A refusal names why: has NO overflow (maxValue=0), already at the top, already at the bottom (900 of 900) — so if it is still wrong, the response should say what it did instead of leaving you to infer it three steps later.

If input_username is still unreachable, the response text on the failing attempt is the thing to paste — it should now distinguish "wrong container" from "scrolled and it is still not there".

There is a new preview workflow on main behind this; anyone can dispatch it from Actions for a branch.

[emooreatx]

Verified on Android through the whole no-AI wizard — 4170176 is the fix. Close from your side whenever you like.

Run #34165538262, preview-scroll-dispatch, Android:

[OK] you_step (23087ms)
[OK] join_federation (1038ms)
[OK] setup_complete (45ms)
[OK] claim_settled
[OK] without_ai_recorded

The movement contract did exactly what you said it would, and it was load-bearing twice on the way here. First it showed the dispatcher fix working (down:300 moved 0→300 of 3118) while our step still failed — which is how I found that our own visibility predicate tested presence and stopped after one scroll. Then, after that fix, already at the bottom (3142 of 3142) terminated the downward phase exactly when travel ran out, and the scroller turned around and found the field. Without the offsets in the 200 and the reason in the 404, both of those would have been another cycle of inference.

Two things from our side, neither needing anything from you:

• Our harness had been reading is_element_visible as "composed", which under registry-never-forgets is always true; it now distinguishes present from on-screen, using the visible field you added in 0.5.206 that we had been dropping on parse. Ours, fixed.
• 300px steps at 0.25s make you_step ~23s on a 3142px form. Fine for a gate; if it ever matters, a larger step or reading of N from the response to jump would cut it. Not asking for anything.

What is left on Android is the same single thing as on every desktop: #43.