Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Add support for Browser Contexts

Open
  • Is something wrong?
#80 0 comments 0 reactions 0 assignees View on GitHub

@davidcockbill is already working on this.

Since Sep 22, 2025.

  • #87 by @davidcockbill — open

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
java
Domain
api

Research direction

Start by reading ChromeRequest and the ChromeDevToolsClient.connect() entry point, then compare their current behavior with the linked Chrome DevTools Protocol flow for Target.createBrowserContext, Target.createTarget, and attachToTarget. Trace how the sessionId should travel across flattened WebSocket messages. Done means callers can create browser contexts and send associated domain messages with the required sessionId.

Written by the indexing model from the issue text.

Description

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.

Dominant language
Java
Stars
48
Forks
19
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from HubSpot/ChromeDevToolsClient

All issues in HubSpot/ChromeDevToolsClient

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.