[🚀 Feature]: No binding runs its BiDi tests against Grid

[AutomatedTester]

Feature and motivation

Every binding has BiDi tests, and most have tests that run against a Grid server, but no binding runs BiDi tests through Grid. So the path where a client speaks BiDi over Grid's websocket proxy (/session/<id>/se/bidi) has no automated coverage in any language, even though the Grid side has supported it for a long time.

The server side works: LocalNode rewrites the returned webSocketUrl to ws://<grid>/session/<id>/se/bidi, keeps the node's real socket as se:gridWebSocketUrl, and ProxyNodeWebsockets.findBiDiEndpoint tunnels it. Node enable-bidi defaults to true.

Verified per binding:

Binding	Status
Python	Now covered. test-<browser>-remote-bidi targets added for chrome and firefox
Java	Not covered — BIDI_BROWSERS in java/defs.bzl is chrome/chrome-beta/edge/firefox/firefox-beta, no remote entry
Ruby	Not covered — rb/spec/tests.bzl generates -remote and -bidi targets in separate branches, never combined
JavaScript	Needs checking — there is a remote/*.js glob and a test/bidi/ directory; whether they intersect was not established
.NET	Needs checking — there is a remote browser config (ActiveDriverConfig=Remote, tagged skip-rbe) and 29 BiDi test files, but whether the BiDi tests run under that config was not established

Usage example

On the Python side this needed no client or conftest change at all — only a Bazel target combining the existing BiDi test sources with the existing Grid test wiring. The suite then passed with zero remote-specific failures across 26 targets on both chrome and firefox; the only two failures reproduced identically without Grid (a headless-Chromium window-focus artifact and a wheel-scroll timing flake, both since fixed).

That suggests the same is likely cheap for the other bindings, and that the coverage gap is a wiring oversight rather than a missing capability. Worth confirming per binding, since each has its own websocket client and the Python one, for example, does not forward ClientConfig auth/TLS settings onto the BiDi socket — a gap this kind of test would eventually expose.

[selenium-ci]

@AutomatedTester, thank you for creating this issue. We will troubleshoot it as soon as we can.

Selenium Triage Team: remember to follow the Triage Guide

[franciscocastillo65]

Since Python was a clean Bazel-only change, we can probably port a similar approach to Java by

[titusfortner]

I'm not convinced this is worth the CI cost. Grid is just proxying the socket, so once the connection is up BiDi traffic is opaque to it. What regressions would the full suite catch that a single test verifying the connection and one event round-trip wouldn't? We're already running a lot of low-value remote targets.

[titusfortner]

The gap that makes sense to cover is the one you mention at the end: client config auth and TLS not reaching the BiDi socket, but your Python PR doesn't include that.