Websocket URL ws://localhost:9222/devtools/browser returns 404

[Jörg Tillmann]

Hi all,

in the latest Canary version (62 for sure, maybe even 61) the generic discovery URL ws://localhost:9222/devtools/browser has stopped working and returns a 404. 

I have not been able to determine the root cause or reason for this. Is anyone aware if this is a bug or a change that's here to stay?

I use that URL to connect via CDP to Canary to create a new Browser Context, create a Target in that Context and then connect via CDP to that new Target. 

Example (Node.js with the chrome-remote-interface module)

const Chrome = require('chrome-remote-interface')

const browser = await Chrome({ target: 'ws://localhost:9222/devtools/browser' });

const { Target } = browser;

const { browserContextId } = await Target.createBrowserContext();

const { targetId } = await Target.createTarget({

    url: 'about:blank',

    browserContextId

});

this.browser = await Chrome({ target: targetId });

This now fails with "Error: unexpected server response (404)"

The test in said module also fails now.

Is that now how to approach this anymore?

Thanks.

[Pavel Feldman]

You should read the browser socket name from the system err of the started browser. Also, I don't think that the code you provide works - there is no Target domain in the browser endpoint, so it should not work.

[Jörg Tillmann]

My example is based on the example in the wiki of the CDP module: https://github.com/cyrus-and/chrome-remote-interface/wiki/Load-a-URL-in-a-separate-context-(headless-mode-only)

It works just fine with Chrome 60 and fails with Canary 62. 

What do you mean by "read the browser socket name from the system err"? Could you please elaborate?

[Andrea Cardaci]

Well Jörg is right, this is unfortunately a breaking change... Pavel, is there a way to obtain this URL programmatically?

> What do you mean by "read the browser socket name from the system err"? Could you please elaborate?

From the terminal where Chrome is started, for example:

DevTools listening on ws://127.0.0.1:9222/devtools/browser/f4f7e416-1c3b-4b4c-b188-1be21ac7097e


Andrea

[Jörg Tillmann]

Andrea, thanks for clarifying, now I get it. 

Of course one can always switch to curling http://localhost:9222/json/list or http://localhost:9222/json/new to create a work around, but the approach via the generic WS URL was much more straightforward.

[Andrea Cardaci]

There is CDP.List and CDP.New for that. The problem is that you cannot create browser contexts in that way.

[Andrea Cardaci]

Quoting from this upstream issue:

The endpoint is available over http://127.0.0.1:9222/json/version in a webSocketDebuggerUrl field. Alternatively, if you are starting chrome with --remote-debugging-port=0, both port and endpoint are written to the DevToolsAcivePort file in browser profile folder.

Also FYI, I updated tests and wiki.