Request to add support for Browser Contexts for better session isolation.
The equivalent puppeteer support is here
Here is an example puppeteer flow:
puppeteer:protocol:SEND ► [ '{"method":"Target.createBrowserContext","params":{},"id":28}' ] +0ms
puppeteer:protocol:RECV ◀ '{"id":28,"result":{"browserContextId":"C3E91703B61927146F87752284522D91"}}'
puppeteer:protocol:SEND ► '{"method":"Target.createTarget","params":{"url":"about:blank","browserContextId":"C3E91703B61927146F87752284522D91"},"id":29}'
puppeteer:protocol:RECV ◀ '{"id":29,"result":{"targetId":"503504648E4964DDF803AA880852DBFF"}}'
// Puppeteer has used Target.setAutoAttach: we'd probably use Target.attachToTarget to get the sessionId
puppeteer:protocol:RECV ◀ '{"method":"Target.attachedToTarget","params":{"sessionId":"545C3C16B43606D627A1BA790C0898BA","targetInfo":{"targetId":"503504648E4964DDF803AA880852DBFF","type":"page","title":"","url":"about:blank","attached":true,"canAccessOpener":false,"browserContextId":"C3E91703B61927146F87752284522D91"},"waitingForDebugger":false},"sessionId":"4B112B2F9D850B67E51015A448C39790"}'
puppeteer:protocol:SEND ► '{"method":"Page.navigate","params":{"url":"http://www.example.com","frameId":"503504648E4964DDF803AA880852DBFF"},"id":47,"sessionId":"545C3C16B43606D627A1BA790C0898BA"}'
The upshot is that the flow above is used to obtain a sessionId (via browserContextId and targetId). This is then used across a single flattened web socket. The sessionId is required in all domain messaging.
So my initial thought are that ChromeRequest needs a sessionId (Note that this is not in the Chrome Dev Tools Protocol definitions; I think it is just implied), and the ChromeDevToolsClient needs an alternative to ChromeDevToolsClient.connect() that allows the user to create Contexts (as shown in the flow above). If using the Context method, then all messages will require the associated sessionId in the ChromeRequest messaging.
Request to add support for Browser Contexts for better session isolation.
The equivalent puppeteer support is here
Here is an example puppeteer flow:
The upshot is that the flow above is used to obtain a sessionId (via browserContextId and targetId). This is then used across a single flattened web socket. The sessionId is required in all domain messaging.
So my initial thought are that
ChromeRequestneeds asessionId(Note that this is not in the Chrome Dev Tools Protocol definitions; I think it is just implied), and theChromeDevToolsClientneeds an alternative toChromeDevToolsClient.connect()that allows the user to create Contexts (as shown in the flow above). If using the Context method, then all messages will require the associatedsessionIdin theChromeRequestmessaging.