Chrome-remote-interface: Question: how to handle multiple incognito/private windows or tabs

[pthieu]

Looked around at docs but couldn't find information. How would I go about generating two tabs that are incognito and are separate sessions?

I want to be able to test a scenario where two users login to an app, and perform a simple interaction on their respective accounts.

[cyrus-and]

I think you are looking for [browser contexts]. You can connect to the special target ws://localhost:9222/devtools/browser to create other targets instead of attaching to a real tab:

const browser = await CDP({target: 'ws://localhost:9222/devtools/browser'});
const {Target} = browser;
const {browserContextId} = await Target.createBrowserContext();
const {targetId} = await Target.createTarget({
    url: 'about:blank',
    browserContextId
});

Then you attach to targetId using a new instance:

function findTargetById(id) {
    return (targets) => {
        return targets.find((target) => target.id === id);
    };
}

const client = await CDP({target: findTargetById(targetId)});
/*...*/

[astarr]

Using the code supplied, with Chrome 59 and 60, I get the following Promise rejection:

Unhandled promise rejection (rejection id: 1): Error: 'Target.createBrowserContext' wasn't found.

I see that createBrowserContext is still listed in the Chrome DevTools documentation, but maybe it's been removed? Do you have any idea what the replacement might be? I need to isolate separate sessions!

[cyrus-and]

I'm trying with both versions and it works:

$ chrome-remote-interface version | grep Browser
    "Browser": "HeadlessChrome/59.0.3071.109",
$ chrome-remote-interface inspect
>>> Target.createBrowserContext()
{ result: { browserContextId: '83e03740-de77-4d32-bf56-79c8df419f1f' } }

$ chrome-remote-interface version | grep Browser
    "Browser": "HeadlessChrome/60.0.3112.40",
$ chrome-remote-interface inspect
>>> Target.createBrowserContext()
{ result: { browserContextId: '616a0c95-790c-4b94-b2c0-12ce4f7446f4' } }

I'm not sure what's happening in your case, that method is defined in those two versions.

[astarr]

Yes, I see it locally, too. It seems that maybe it's available as a function in the client, but not on the browser? I have no idea what I'm talking about. This works for me:

const [tab] = await CDP.List()
const client = await CDP({ host: '127.0.0.1', target: tab })

This fails with the promise rejection on the createBrowserContext() line:

const browser = await CDP({target: 'ws://localhost:9222/devtools/browser'});
const {Target} = browser;
const {browserContextId} = await Target.createBrowserContext();
const {targetId} = await Target.createTarget({ url: 'about:blank', browserContextId });
function findTargetById(id) {
  return (targets) => {
    return targets.find((target) => target.id === id);
  };
}
const client = await CDP({target: findTargetById(targetId)});

[cyrus-and]

It seems that maybe it's available as a function in the client, but not on the browser?

In the above examples, Target.createBrowserContext() is actually called, as you can see by the result, it's not just a matter of local protocol file.

[astarr]

I do see that, now. I'm not sure what's happening to me, but I appreciate your help. Best,

[astarr]

It only works for headless chrome. I was debugging with a chrome instance that was not launched headless, so I could watch along and see what was happening. You can't create a browser context that way. It works swimmingly for headless chrome. Thank you so much for your help!

[cyrus-and]

Yes, Target.createBrowserContext only works in headless mode, but the error in that case is different:

$ chrome-remote-interface inspect
>>> Target.createBrowserContext()
{ error: { code: -32000, message: 'Not supported' } }

Anyway, glad you've found a solution. :)

[incubus]

Hi!

How to use the browser context with the Canary version (62.0.3188.0)?

const browser = await CDP({target: 'ws://localhost:9222/devtools/browser'}); returns 404 error.

But this code works with 60.0.3112.90 version.

[cyrus-and]

@incubus unfortunately the browser target (ws://localhost:9222/devtools/browser) is no more available in 62 with that URL, AFAIK you have to manually fetch it from the terminal in which you run Chrome, which makes all this quite useless.

I'm still waiting for a reply here.

[incubus]

So sad... Thanks for the info!

[cyrus-and]

FYI upstream issue.

[cyrus-and]

I'm quoting the comment in that 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.

[incubus]

Thanks!

[GuacheSuede]

@cyrus-and would they no share the same cookies though since it belongs to the same url, do contexts separate cookies ?

[cyrus-and]

@GuacheSuede AFAIK each browser context has its own cookies, local storage and everything.

[GuacheSuede]

ah great, Thanks

[gitinthehole]

Only as a shortcut for those digging for this issue, check out the linked Google Groups issue linked by @cyrus-and and check out the Andrea's updated docs at https://github.com/cyrus-and/chrome-remote-interface/wiki/Load-a-URL-in-a-separate-context-(headless-mode-only) This was a huge help solving this mystery! Thank you Andrea!

[mattcodez]

This is exactly what I'm looking for. I can't seem to find a way to perform browser level tasks per context however. Like setCookie is only on the client's Network object and doesn't take a target for a parameter. So how would I set a cookie for only a given context?

[cyrus-and]

@mattcodez once you connect to a given target you can set a cookie in that target. You don't need a target parameter since it's a connection-oriented interaction.