WebDriverAgent 16.14.1 stops sending its idle check to WebKit; phoneshell had the check on for 189 web runs and its grader still read the page in 29 of 30

The bug needs two things: the deadline turned on, and a snapshot request aimed at an element that lives in WebKit's process. phoneshell has the first. Its published runs suggest it does not make the second, and its code says why.

WebDriverAgent 16.14.1, released on 7 October 2026, stops sending its accessibility idle check to WebKit's content process, which the check had been crashing, leaving web pages blank. phoneshell has run the affected code since 8 September: WebDriverAgent 16.12.4 with accessibilityDeadline set to 10 seconds. In the 189 web-content runs it has published since that setting, the grader found "Example Domain" in the accessibility tree 29 times out of 30. With no screenshot sent at all, the text probes passed 30 of 30.

What changed on 7 October

The setting arrived in WebDriverAgent 16.8.0 on 24 August 2026 (PR #1214). It is off by default. When it is above zero, a swizzle on requestSnapshotForElement first asks the target app, through the private notifyWhenEventLoopIsIdleForApplication: call, whether its run loop is alive, and aborts the snapshot if no answer comes inside the deadline. The point was to stop one hung app from blocking the whole server (issue #1210).

The target app is resolved from the element's own process id. On 5 October, GitHub user bddsko reported (issue #1290) that elements inside a WKWebView are remote accessibility elements owned by com.apple.WebKit.WebContent, so the idle-check action went there. WebContent does not implement it, throws an unrecognized-selector exception and aborts about 1.5 seconds into the page load. WebKit reloads once, crashes again, and gives up; every lookup on the page then times out. The report used Appium 3.8.0, xcuitest driver 12.13.3, WebDriverAgent 16.12.11 and an iOS 18.3.1 simulator with the deadline at 30.

The fix (PR #1293, shipped in 16.14.1 at 03:49 UTC) adds eight lines: when the resolved process's bundle id starts with com.apple.WebKit., call the original snapshot and skip the check. Its author validated it on an iPhone 17 simulator on iOS 27.0, with a negative control that returns a nil snapshot without the fix, and says the original iOS 18.3.1 crash environment was not available. No physical device was tested. The same release also fixes screen geometry on the selected display (#1291), and xcuitest driver 12.15.1 and 12.15.2 followed the same day.

phoneshell's web runs with the check switched on

phoneshell pins WebDriverAgent at v16.12.4 (WDA_TAG in device.py), and the vendored copy carries the swizzle exactly as the issue describes it. Its session settings in config.py set accessibilityDeadline: 10.0, added in commit f0c538d at 04:53 UTC on 8 September. Every cross-model run published on the Hugging Face dataset came after that. We counted the web-content tasks in those files: the Safari tasks, the twenty probe pages on blolabel.ai, and resilience.deep_start, which ends on example.com.

A blank page would show up in three places at once: the "Example Domain" checks, which are a WebDriverAgent tree read by the grader itself rather than anything the model says; the text probes run without a screenshot, where the tree is the only channel the model has; and the turn counts. The first two came back at 29 of 30 and 30 of 30. The one heading miss is a run that started three levels deep in Settings, and nothing in the row says whether the page was blank or never loaded. One run, so treat it as unexplained rather than as a sighting of the bug.

Why the check never reached WebKit here

The crash needs a snapshot request aimed at an element whose process is WebContent. phoneshell perceives the screen with one GET /source per observation, which snapshots the application root: the process id is MobileSafari's, Safari answers the idle check, and the web subtree comes back inside that one snapshot. Taps go to /wda/tap as coordinates. The only element lookups in the action layer (actions.py, around line 974) find a text field to type into, and in these tasks that field is Safari's own address bar. That is our reading of the code, not a trace from the phone, which has been parked under runtime/automation-off since 17 September.

The rows also say less than we would like about the hardware. The xv2 rows record an iPhone 14 Pro on iOS 26.3.1. The other files record no device. The issue was an iOS 18.3.1 simulator, the fix was tested on an iOS 27.0 simulator, and nobody in the thread reports a physical phone. So the evidence is two-sided and partial: the bug is real on a simulator, absent from 189 iOS 26 hardware runs that never made the triggering request.

What it means if you run WebDriverAgent with a deadline

• The exposure is a combination: 16.8.0 to 16.14.0, accessibilityDeadline above zero, and element-level requests inside a web view (find by link text, read a web element's rect or value, hybrid tests that stay in the native context). If all three hold, upgrade to 16.14.1.
• Setting the deadline back to zero removes the crash and brings back the problem it was added for: one app that stops answering accessibility requests can block the server indefinitely. phoneshell keeps 10 seconds for that reason.
• An agent that reads through /source and taps coordinates sends far fewer per-element requests than a test script does. That is why one class of WebDriverAgent bug passes it by. It is also why its timing numbers are not comparable with Appium element-based suites.
• A deterministic tree check on the grader side is what makes this question answerable after the fact. Model-reported success would have hidden a blank page that the model guessed around.

Check it yourself

# the fix and the code it changes
gh api repos/appium/WebDriverAgent/pulls/1293/files --jq '.[0].patch'
curl -s https://raw.githubusercontent.com/appium/WebDriverAgent/v16.12.4/WebDriverAgentLib/Categories/XCAXClient_iOS+FBSnapshotReqParams.m | grep -n "processIdentifier\|notifyWhenEventLoopIsIdle"

# phoneshell's settings and pin
grep -n "accessibilityDeadline" phoneshell/config.py
grep -n "WDA_TAG" phoneshell/device.py
grep -n "def source\|/wda/tap" phoneshell/wda/client.py

# the published runs
for f in exp2-n exp2-v v4 xv-novision xv-text xv xv2; do
  curl -sLO https://huggingface.co/datasets/blolabel/phoneshell-bench/resolve/main/results/$f.jsonl; done
# keep rows with started_at >= 1788843209 (2026-09-08T04:53:29Z) and task_id starting
# safari., probe., or equal to resilience.deep_start; group failures by the first failing check

What would prove this wrong

By 31 December 2026 we will run the six Safari tasks twice on an iOS 26 iPhone, once on 16.12.4 and once on 16.14.1, both with the deadline at 10 seconds, adding one element lookup on the example.com link before each tap. Our prediction: on 16.12.4 the lookup blanks the page in at least half the runs, and on 16.14.1 in none. If 16.12.4 survives the lookups as well, the crash is specific to the simulator or to iOS 18, and the fix matters less on current hardware than the issue suggests. If /source alone ever produces a blank page on 16.12.4, our explanation of why phoneshell escaped is wrong.

Sources

• appium/WebDriverAgent, release v16.14.1, 7 October 2026; PR #1293, "skip accessibility idle checks for WebKit services".
• bddsko, issue #1290, "accessibilityDeadline crashes WKWebView's WebContent process", 5 October 2026.
• appium/WebDriverAgent, PR #1214, "bound accessibility snapshot requests to avoid indefinite hangs", merged 24 August 2026, released in 16.8.0; v16.12.4, 6 September 2026.
• Blolabel, phoneshell: phoneshell/config.py, device.py, wda/client.py, actions.py, read 7 October 2026.
• Blolabel, phoneshell-bench, results/, runs of 8 and 9 September 2026.