Highlights
✨ Web Inspector CDP: the landing page names the version serving it
The header of the bridge's landing page (pymobiledevice3 webinspector cdp) now reads pymobiledevice3 <version> · inspectable pages and JSContexts on the device, so a page open in a tab tells which installation is behind it. A bare checkout without the package's generated version module shows the name alone.
📝 Web Inspector CDP: how to reach chrome://inspect, and why the landing page is preferred
Chrome refuses every navigation to a chrome:// URL that originates in a web page, clicked or scripted, so the landing page cannot link to chrome://inspect. A collapsed Using chrome://inspect instead note now explains what to do for those who want it anyway: type chrome://inspect/#devices into the address bar, rely on Chrome discovering a bridge on localhost:9222 by itself, or add the bridge's own address (filled in on the page) under Configure... next to Discover network targets. It also repeats why the landing page is the better route: chrome://inspect sends DevTools through Chrome's browser-process relay, which deadlocks under sustained console traffic and freezes the console and screen, whereas the landing page's links connect to the bridge directly. The WebView debugging guide carries the same notes.
pymobiledevice3 webinspector cdp
# open http://127.0.0.1:9222/ in Chrome - the header names the serving versionWhat's Changed
- a2a9ed8 cdp: Name the serving pymobiledevice3 version on the landing page, and explain chrome://inspect (#1918) (@doronz88)
Full Changelog: v11.8.0...v11.9.0