Added info on how to find the browserWSEndpoint

[JakeGinnivan]

It took me a while to figure this out, thought it may help others.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If your company signed a CLA, they designated a Point of Contact who decides which employees are authorized to participate. You may need to contact the Point of Contact for your company and ask to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the project maintainer to go/cla#troubleshoot.
• In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again.

[JakeGinnivan]

I signed it!

[googlebot]

CLAs look good, thanks!

[aslushnikov]

ironically, this is page's debugging URL, not browser's. It might work for now, but might not eventually.

The Browser WS is dumped by the browser in its stderr. Note: this only happens if the browser is launched with a remote-debugging-port flag.

Check out how we extract browser web socket from stderr in the Launcher.js

[aslushnikov]

Hey @JakeGinnivan, thank you for the PR! Could you please share your user scenario - why would you need a way to get the browser endpoint manually?

[JakeGinnivan]

Yeah sure.

We are doing visual regression testing and have mac, windows and linux machines. To remove differences like font rendering etc we are just using the docker container alpeware/chrome-headless-unstable and having it run on our build server and all developers machines in the background.

I figured it was the page debugging endpoint but couldn't figure out how to resolve the browsers endpoint.

[aslushnikov]

@JakeGinnivan do you want to update this PR with a relevant information to ease the life of future generations? Feel free to close it if you don't.

[paulirish]

btw see "How do I access the browser target?" on ChromeDevTools/devtools-protocol#55 ..

i'll be moving that into the real site soon... so that is probably a better place to document the browserWs endpoint details than here.

(So i'd recommend nuking L231 and instead linking up that doc)

[JakeGinnivan]

Will get this updated today, appreciate the info!

[JakeGinnivan]

@paulirish I have done both for the moment. The redundant info can be removed later if need be but having it directly in this doc I think will be handy for people.

[pierre-moire]

Actually the url is /json and not /json/version to get the debugger url

[paulirish]

@pierre-moire /json lists page endpoints, the browser endpoint is only available at /json/version.

[paulirish]

you can just update this to point to https://chromedevtools.github.io/devtools-protocol/#faq

(it will deploy soon if it hasn't already)

[JakeGinnivan]

@paulirish updated.

The FAQ header is missing an anchor so I anchored directly to the interesting header

[googlebot]

So there's good news and bad news.

👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there.

😕 The bad news is that it appears that one or more commits were authored by someone other than the pull request submitter. We need to confirm that they're okay with their commits being contributed to this project. Please have them confirm that here in the pull request.

Note to project maintainer: This is a terminal state, meaning the cla/google commit status will not change from this State. It's up to you to confirm consent of the commit author(s) and merge this pull request when appropriate.

[kachkaev]

Hi guys, a newbie here :–)

Seems like going to http://localhost:9222/json/version to figure out the webSocketDebuggerUrl did not help in my case. The json being returned is:

{
   "Browser": "Chrome/61.0.3163.100",
   "Protocol-Version": "1.2",
   "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36",
   "V8-Version": "6.1.534.41",
   "WebKit-Version": "537.36 (@57c9d07b416b5a2ea23d28247300e4af36329bdc)"
}

Launching Chrome on macOS with open '/Applications/Google Chrome.app' --args --remote-debugging-port=9222.

Ultimately I'm trying to set up Chrome as a docker microservice and talk to it using puppeteer from a Node.js microservice. All works when the browser is in the same container and I launch it with puppeteer.launch, but the image becomes not so micro in this case 😄