SeleniumHQ / SeleniumHQ/selenium
[🚀 Feature]: No binding runs its BiDi tests against Grid
- Dominant language
- Java
- Stars
- 34.5k
- Forks
- 8.7k
- Avg merge
- 2d 1h
- Merged PRs (30d)
- 92
Description
### 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//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:///session//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--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.
Contributor guide
Assessment
This issue has not been assessed yet.