Highlights
✨ Web Inspector CDP: the landing page shows who is debugging each target
The device reports the Web Inspector connection attached to every debuggable - JSContexts included, not only web pages - but the bridge (pymobiledevice3 webinspector cdp) dropped it for JSContexts and never rendered it, so a context someone else was already debugging looked free and opening it came up blank. Every target on the landing page now carries a badge saying who holds it: attached here for a session of this bridge (opening it takes it over), held elsewhere for another Web Inspector connection such as Safari's own Web Inspector or a second pymobiledevice3, alongside the existing paused badge.
✨ Web Inspector CDP: targets grouped by process, with icons, folding and a filter
Targets are grouped under a header per process with the icon the device sends, the process name, bundle identifier, pid and target count. Web pages previously showed no owning app at all, and every JSContext of a process is now labelled by its number alone under that header. Groups fold on their header and stay folded while the list refreshes. A filter box narrows the list to targets matching every word typed, by title, URL, process name, bundle identifier or pid - handy with a process exposing a dozen identically named JSContexts.
Hovering a page target highlights its view on the device screen, as Safari's Develop menu does. A process that accepts Remote Automation sessions carries an automation badge, a process running web content for another names the app it runs in, and Chrome's /json/list entries carry the process icon as faviconUrl for chrome://inspect.
pymobiledevice3 webinspector cdp
# open http://127.0.0.1:9222/ in Chrome: pick a target, fold a process, type in the filter box📚 WebView debugging guide corrections
The guide's WebStorm section now states how the bridge translates Debugger.setSkipAllPauses (into deactivating breakpoints and debugger statements) rather than describing it as an error, explains the jscontext:// URL as behaviour rather than history, and spells out all three cases of a held page: taken over from a session of this bridge, skipped by browser-level clients, or held over a different Web Inspector connection. The README highlights now mention the CDP bridge.
What's Changed
- 53a7d48 cdp: Highlight hovered pages on the device, filter the landing page, and show what else the listing knows (#1917) (@doronz88)
- eef19e1 cdp: Show who is debugging each target, and group the landing page by process (#1917) (@doronz88)
- 4cf3fa8 docs: Mention the CDP bridge in the README highlights (#1916) (@doronz88)
- 959530a docs: Correct the WebView debugging guide's WebStorm and takeover notes (#1916) (@doronz88)
Full Changelog: v11.7.0...v11.8.0