bidi: protocol selection CLI, start of [classic] WebDriver

In order to support Selenium the way people are used to, it looks  like we need
to support both WebDriver classic (WebDriver) and WebDriver BiDi (BiDi). Typical
scripts look like a mix of the two, e.g. using WebDriver to control the browser
and using BiDi  to receive notifications. This commit:

1 - adds a --protocol (cdp|webdriver) CLI argument to the `serve` command to
    enable one or the other protocol (defaulting to CDP)

2 - adds basic WebDriver endpoint to let a Selenium client connect. This
    implementation is hackish and sits on top of our simple Handshake handler.

The handshake handler is well past its original design. Serving /json/version
and /metrics from it was one thing. But Driving the entire browser session? This
will get a follow up PR.
This commit is contained in:
Karl Seguin committed 2026-08-31 22:45:15 +08:00
1 parent 5c0ed733d2
commit 766c0d05d6
8 files changed
+409 -50

No files matched your search

+2 -1
View File
@@ -511,7 +511,7 @@ const Server = @import("server/Server.zig");
const TestWSServer = @import("TestWSServer.zig");
const TestHTTPServer = @import("TestHTTPServer.zig");
var test_cdp_server: ?*Server = null;
pub var test_cdp_server: ?*Server = null;
var test_cdp_server_thread: ?std.Thread = null;
var test_http_server: ?TestHTTPServer = null;
var test_http_server_thread: ?std.Thread = null;
@@ -613,6 +613,7 @@ fn serveCDP(wg: *lp.WaitGroup) !void {
std.debug.print("CDP server error: {}", .{err});
return err;
};
test_cdp_server.?.protocols = .{ .cdp = true, .webdriver = true };
wg.finish();
test_cdp_server.?.run();