Highlights
🐛 The DevTools frontend is no longer fetched through an HTTP proxy
When the CDP bridge serves its DevTools frontend from a locally launched Chrome, it reaches that Chrome over loopback — and the fetch was going through whatever proxy happened to be configured. urllib applies proxy configuration to loopback as readily as to anything else: proxy_bypass_environment consults only no_proxy, and macOS' ExceptionsList/"exclude simple hostnames" cannot match 127.0.0.1, which is exactly the form the fallback hands back. With a proxy set, the bridge dialled it to reach a Chrome running on the same machine, every asset came back empty, and DevTools opened blank — while the landing page and the bridge's own WebSocket kept working, since browsers bypass loopback implicitly.
Anything addressed to this machine is now fetched through an opener with an empty ProxyHandler. The hosted build stays on the default opener, so a proxy genuinely needed to reach it is still used.
A failed frontend lookup is also no longer remembered: it used to be cached as an empty base and short-circuited on, so a single unlucky attempt served 404s — a permanently blank window — for the rest of the session.
pymobiledevice3 webinspector cdp
# then open http://127.0.0.1:9222/ and pick a page🐛 Reattaching to Web Inspector no longer fails as "Web inspector is not enabled"
webinspectord admits a new session only about ten seconds after the previous one started — measured from the start, so closing early does not help. Until the gate lifts it accepts the connection but never completes the TLS handshake, and that is a hair longer than the handshake timeout. Restarting the CDP bridge, opening an automation session once inspection was done, or simply running the Web Inspector tests in sequence therefore failed, and because a disabled device also terminates the connection, the abort was reported as Web inspector is not enabled — pointing at a Settings toggle that was never off. The attempt that timed out has itself waited the gate out, so the connection is retried once.
🐛 A second run of the CDP bridge in one process no longer wedges
The bridge's per-page state lived for the whole process, but its asyncio primitives belong to the event loop that created them, and a page handler killed without unwinding leaves its lock held. Carried into a later run in the same process, every connection to that page waited out the full handover timeout for a lock nobody was left to release, then failed outright because the lock belonged to a loop that was gone. That state is now reset at startup, so each run begins from primitives of its own loop.
🐛 A page held by another debugger says so
A page already being debugged over a different Web Inspector connection — a second pymobiledevice3, Safari's own Web Inspector, or a client that exited without detaching — never reports an inspection target, and both attach paths blamed the device for it. The page listing has carried the holder's connection identifier all along; it is kept for web pages now, the way automation targets already keep it, and named in the error instead.
What's Changed
- 4bd61a7 webinspector: name the connection already debugging a page (#1889) (@doronz88)
- 1935287 webinspector: reset the CDP bridge's per-page state on every run (#1889) (@doronz88)
- 3890684 webinspector: retry the connection webinspectord gates after a session (#1889) (@doronz88)
- 600dddc webinspector: retry a DevTools frontend that could not be resolved (#1889) (@doronz88)
- c4dfb39 webinspector: fetch the fallback DevTools frontend without a proxy (#1889) (@doronz88)
Full Changelog: v11.2.1...v11.2.2