-
Notifications
You must be signed in to change notification settings - Fork 0
open_session.notes
browser picks which. The default is chrome, and every other action behaves
identically on both — this is the only call that changes, which is the whole
reason a second browser costs so little: both are plain W3C WebDriver, so only
session creation differs.
{"browser": "firefox", "width": 1400, "height": 900}Reach for Firefox when the task is about Firefox — confirming a rendering difference, or a site that treats the two differently. Otherwise leave it alone.
Three things worth knowing:
-
A session cannot switch browser. To compare the two, open one session per
browser and keep both ids.
session://currentreports which browser the session you are holding is running. - The Grid has to offer it. With no Firefox node registered, a Firefox request sits in the Grid's session queue until it times out — which looks like a slow open, not an error. That is Grid capacity, not a server setting. Where the browser nodes scale from zero, the first open of a browser also pays a cold start while a node boots.
- A reaped session comes back as the same browser. The choice is stored with the session, so the transparent reopen after the Grid expires an idle browser does not silently drop you onto the default one.
An explicit browser is validated strictly: "chrom" is an error rather than a
quiet fall back to Chrome. The server-side default (DEFAULT_BROWSER) and the
client-side one (?browser= / X-Browser) are lenient like every other
setting, so a typo in a deployment's environment cannot stop a browser opening.
The action pages are generated from openapi.yaml, which is itself generated from the live MCP tool schemas — so they describe the server that shipped, not the one someone remembered. Prose belongs in wiki-notes/<tool>.md in the repo.
selenium-flow · MIT
Start here
Lifecycle
Going places
Doing things
Getting things out