iOS on BrowserStack: snapshot fails SESSION_NOT_FOUND on live sessions; fill silently no-ops or mis-navigates on WebView inputs

[TilakVattikuti]

Summary

Two related bugs found testing an iOS app against BrowserStack App Automate real devices via agent-device 0.20.5, both isolated to the cloud-webdriver iOS path (local iOS and Android+BrowserStack were not affected).

Bug A: snapshot fails with SESSION_NOT_FOUND on a genuinely live, verified session

CONNECT_OUT=$(agent-device connect browserstack --platform ios --device "iPhone 16" \
  --provider-os-version 18 --provider-app bs://<app-id> --force --json)
SESSION_NAME=$(echo "$CONNECT_OUT" | jq -r .data.session)
agent-device open com.example.app --session "$SESSION_NAME"   # "Opened: ..."
agent-device snapshot -i -c --session "$SESSION_NAME"

Error (SESSION_NOT_FOUND): iOS snapshot requires an active app session on the target device.
Run open first (for example: open --session browserstack:adc-xxxxxx --platform ios --device "<name>" <app>).

This happens instantly (0ms in the request log) with no runner.log ever created for the session — looks like a local pre-check, not a real driver round-trip. At the same moment:

• agent-device connection status --session "$SESSION_NAME" --json reports connected: true, liveSession.status: "created".
• agent-device artifacts --json --session "$SESSION_NAME" returns a real providerSessionId with a working BrowserStack video URL.
• press, find, fill, screenshot, appstate all work normally against the exact same --session on the exact same live device.

Reproduced 100% of the time across 4 independent device/OS combinations: iPhone 16/iOS 18, iPhone 17/iOS 26, iPhone 16 Pro/iOS 18, iPad Pro 11 2025/iOS 26.

Not a duplicate of #1596 — that issue is about a daemon-replacement crash path (already fixed via #1603). This reproduces with no daemon replacement involved, against a session that was never anything but healthy.

Bug B: fill silently no-ops or mis-navigates on WebView inputs

Target: a Safari view controller (ASWebAuthenticationSession) hosting a web-based OAuth/SSO login page, opened from the native app.

agent-device fill 'editable=true' "user@example.com" --session "$SESSION_NAME"
# -> "Filled 13 chars"
agent-device screenshot after.png --session "$SESSION_NAME"
# -> field visually still shows placeholder text, no cursor, no keyboard

Observed across devices, varying which field and how badly:

• iPhone 16 Pro/iOS 18: password field specifically no-op'd twice in a row; email field worked every time.
• iPad Pro 11 2025/iOS 26: both email and password fields no-op'd on first attempt; two consecutive blind retries on email also no-op'd.
• iPhone 17/iOS 26: fill and press+type both resolved to a coordinate far from the actual field (near the top of the screen); on a separate attempt the same sequence caused the WebView to navigate entirely away to the app's public marketing site instead of the field being filled — a stray-tap symptom similar in shape to the local-runner bug fixed in perf+fix(ios): faster text entry (readiness + typed-query field resolve) + fix fill mis-navigation #633, but here on the cloud-webdriver path, which perf+fix(ios): faster text entry (readiness + typed-query field resolve) + fix fill mis-navigation #633 didn't touch.

Confirmed 100%-reliable workaround, across every device/field it was tried on: explicitly focus the field first with a targeted tap (find <label> click or press), then call fill. A blind fill with no preceding focus tap is unreliable on this path.

Environment

• agent-device 0.20.5 (fill flakiness also present on 0.20.0)
• macOS host
• BrowserStack App Automate, real iOS devices
• connect used with no --config/--session override; ids captured from --json's data.session

Ask

Root cause + fix for (a) snapshot's iOS+cloud-provider active-session check, and (b) fill's WebView-input reliability on the cloud-webdriver path — possibly the same "don't trust a stale/pre-focus frame" discipline #633 added to the local Apple runner, ported to cloud-webdriver.