Issue metadata
Sign in to add a comment
|
can't inspect chromecast target built @ HEAD from chrome desktop M63 |
||||||||||||||||||||||
Issue description
Inspecting a target built at HEAD from stable is not working presently and results in a blank page with following error:
Uncaught TypeError: InspectorFrontendHost.setOpenNewWindowForPopups is not a function
at Main.BackendSettingsSync._updateAutoAttach (inspector.js:8623)
at new Main.BackendSettingsSync (inspector.js:8621)
at Main.Main._createAppUI (inspector.js:8565)
at Main.Main._gotPreferences (inspector.js:8555)
at DevToolsAPIImpl.embedderMessageAck (devtools_compatibility.js:33)
at <anonymous>:1:13
This seems to be calling a function that was not added yet in M63.
Inspector UI is loaded from:
chrome-devtools://devtools/remote/serve_rev/@91ec42827a81873f7e254959c0821b01ddcd4531/inspector.html?remoteFrontend=true&dockSide=undocked
I tried looking into it but ran into some questions.. are the loaded JavaScript UI resources supposed to match the target browser's version, or the frontend host's version ?
,
Jan 19 2018
,
Jan 22 2018
Unfortunately, we do not support forward-compatibility. That means frontend for the newer version of remote device (HEAD in your case) may not run on older version of host browser (M63 in your case). I can probably fix this particular instance, but the general advise is to use Canary or custom build if you have to inspect fresh remote devices.
,
Jan 22 2018
Ok, that's good to know... but do you know why inspecting chrome seems to work? The chrome case seems to be forward compatible, by loading the older UI resources for M63 (@2e6edcfee630baa3775f37cb11796b1603a64360) The chromecast case loads the newer UI resources for M65 and breaks (@eb834e33c71d4a5a7ef8da7bb293bb975606ff36). I am still confused about the difference in behavior here.. hence the question about what the expectation is for resource versioning.
,
Jan 22 2018
Inspecting chromecast and remote chrome should be similar in this regard - they should both load frontend corresponding to the backend version. Fro Chromecast, it comes from the cloud, Chrome might bundle one with itself.
,
Jan 22 2018
Hm, that doesn't match my observations. Inspecting M65 linux chrome built at HEAD from M63 linux chrome uses the frontend for M63 (@2e6edcfee630baa3775f37cb11796b1603a64360) which allows it to work.
,
Jan 22 2018
How exactly do you inspect M65 from M63 (chrome://inspect with local ip address, android via usb, websocket url, something else)?
,
Jan 22 2018
I just ran ./out/linux_rel/chrome --remote-debugging-port=9222 and inspected localhost. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by spang@chromium.org
, Jan 19 2018I bisected and this is broken for us as of [DevTools] Move "auto open DevTools for popups" from protocol to embedder This is an embedder feature, not the protocol one. As a side bonus, this unblocks DevToolsAgent migration to blink. Bug: 776009 Change-Id: I5c8f18ec0d8f07a556a7630f0d534fbb779d7fdf Reviewed-on: https://chromium-review.googlesource.com/837509 Reviewed-by: Daniel Cheng <dcheng@chromium.org> Reviewed-by: Andrey Kosyakov <caseq@chromium.org> Reviewed-by: Pavel Feldman <pfeldman@chromium.org> Commit-Queue: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#526578}