Error: Unable to fetch webSocketDebuggerUrl with headless_shell

I realize this is on the edge, but currently when running lighthouse-cli or using lighthouse-core in custom scripts, cri.js will throw an error and exit when running against the headless_shell built from the tip (as of Nov 17):

status Disconnecting from browser... +0ms
Runtime error encountered: Error: Unable to fetch webSocketDebuggerUrl, status: 500
    at IncomingMessage.response.on._ (/usr/local/lib/node_modules/lighthouse/lighthouse-core/gather/connections/cri.js:79:18)
    at emitNone (events.js:91:20)
    at IncomingMessage.emit (events.js:185:7)
    at endReadableNT (_stream_readable.js:974:12)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)

This is caused by CriConnection connect() method calling /json/new. In this case, headless_shell will return “Cannot create new page” as the /json/new API does not exist in headless_shell as per https://bugs.chromium.org/p/chromium/issues/detail?id=626847.

My question: leave the existing behavior and wait for 626847 to add the the backwards compatibility for /json/new or handle this in the new Browser.createTarget DevTools command?

Note: if anyone is reading this and you still want to run against headless_shell now, you can temporarily peg to 1.1.6 before the Connection refactor occurred.

[pavelfeldman]

We need to do something on chromium side to make you happy. Just filed this: https://bugs.chromium.org/p/chromium/issues/detail?id=666865. Once it is fixed, you can issue “Target.createTarget” while connected to the predefined “ws://localhost:9222/devtools/browser” endpoint. We might want to throw a secure GUID into that path to protect your clients from random pages attempting to connect to the endpoint. That way it does not require the flag, but you need to have a way of parsing the GUID out from the chrome stdout.

[paulirish]

We need to do something on chromium side to make you happy. Just filed this: https://bugs.chromium.org/p/chromium/issues/detail?id=666865. Once it is fixed, you can issue “Target.createTarget” while connected to the predefined “ws://localhost:9222/devtools/browser” endpoint.

FYI: A patch is up for this https://chromium-review.googlesource.com/c/596719