// STRYKE-SELENIUM — BROWSER AUTOMATION FOR STRYKE // WEBDRIVER + DOM + JS + COOKIES

Install

thirtyfour ships with rustls-tls in the default feature set, so there are no OS-side build deps beyond a working Rust toolchain — no openssl, no Wayland / X11 stack. Just:

s pkg install -g github.com/MenkeTechnologies/stryke-selenium

Pin a specific release:

s pkg install -g github.com/MenkeTechnologies/stryke-selenium@v0.17.0

This fetches the prebuilt tarball for your host triple (aarch64-apple-darwin, x86_64-apple-darwin, x86_64-unknown-linux-gnu, aarch64-unknown-linux-gnu), verifies its SHA-256, extracts into ~/.stryke/store/stryke-selenium@<version>/, and registers the cdylib for use Selenium. No cargo, no rustc, no per-target build step on the user's machine.

You also need a WebDriver server (chromedriver / geckodriver / safaridriver) running — see the WebDriver server section below.

Quick start

use Selenium

# launch a browser
Selenium::open(browser => "chrome", headless => 1)

# navigate + read
Selenium::goto("https://example.com")
p "title: " . Selenium::title()
p "url:   " . Selenium::current_url()

# find + interact
val $h1 = Selenium::find("h1")
p "h1 text: " . Selenium::text($h1)

# wait + click
val $btn = Selenium::wait_for("button.submit", "css", 10)
Selenium::click($btn)

# screenshot
Selenium::screenshot("/tmp/page.png")

# clean up
Selenium::quit()

API: Selenium::*

Every function lives in the Selenium:: namespace (use Selenium). The last optional argument on most browser-bound calls is $sid — the session id returned by Selenium::open. Omit it to use the active session. Element ops take the element id $eid returned by find / find_all / wait_for. The pure helpers at the end open no browser session at all — they are string parsing / validation that runs without a WebDriver server.

Session lifecycle

Navigation & timeouts

Element queries

$by values: css (default), id, name, xpath, tag, class, link_text, partial_link_text. Each has short aliases (css_selector, tag_name, class_name, link, plink) — see Selenium::locator_strategies().

Element ops

JavaScript

Action chains

Low-level pointer/keyboard sequences for cases a plain click/send_keys can't express.

Screenshots & scrolling

Window / frame

Alerts

Cookies

Pure helpers (no browser)

These open no session — string parsing / validation that runs without a WebDriver server:

The same list, with full per-argument notes, lives in the README API reference.

WebDriver server

stryke-selenium is a client. You launch the WebDriver server yourself. One-liners per browser:

# Chrome — default. Matches Selenium::open() with no url arg.
brew install --cask chromedriver
chromedriver --port=9515 &

# Firefox — pass url => "http://localhost:4444" to Selenium::open.
brew install geckodriver
geckodriver --port 4444 &

# Safari — macOS only; one-time enable:
safaridriver --enable
safaridriver -p 4444 &

# Edge — install msedgedriver matching your Edge version.
msedgedriver --port=9515 &

# Selenium Grid 4 (all browsers via one server):
brew install selenium-server
selenium-server standalone --port 4444 &

To verify the install + FFI roundtrip without launching a browser:

selenium-test            # installed at ~/.stryke/bin/selenium-test by `s pkg install -g`

Why a cdylib, not a sidecar binary

Two competing models for stryke connectors:

• Sidecar binary — the connector ships a regular Rust binary; the .stk wrapper fork(2) + exec(2)s it per call, parsing JSON over a pipe. Simple, ABI-stable, isolates crashes — but every call pays a process-creation cost plus any per-call session-init cost the binary has (Enigo handshake, WebDriver session resume, …).
• cdylib (this package) — the connector ships a shared library; stryke dlopens it once per process and registers each export as a stryke-callable function. Calls are direct function calls with no fork / exec — just JSON-in / JSON-out across the FFI boundary.

For Selenium the second model is mandatory: a WebDriver session is an HTTP keep-alive pool plus a server-side browser process, both of which take hundreds of milliseconds to set up. Paying that per Selenium::* call would make any non-trivial script unusable. The cdylib holds the WebDriver handle in a process-global OnceCell<Mutex<HashMap<u64, WebDriver>>> so one Selenium::open serves the whole script.

thirtyfour is async (tokio), but the stryke FFI is sync. The cdylib bridges via a single process-global tokio::runtime::Runtime built on first FFI entry; every handler is runtime.block_on(async { … }). A fresh runtime per call would be ~1 ms of pure tokio bring-up overhead — fine in isolation, ruinous across thousands of Selenium::* calls.

FFI protocol

Every selenium__* export takes a JSON-encoded args dict and returns a JSON-encoded result. The lib/Selenium.stk wrapper builds the args, calls the FFI symbol, and parses the return. Errors come back as {"error": "<message>"} — the wrapper recognizes this shape and dies with a descriptive message.

To pass a Selenium WebElement as a JS arg, wrap it as { __element__ => $eid }. The cdylib detects this shape and unmarshals it into a real DOM element on the JS side. Mirrors selenium-python's execute_script(…, web_element) convention.

Examples

Layout

stryke-selenium/
├── stryke.toml             # stryke package manifest with [ffi] table
├── Cargo.toml              # stryke_selenium cdylib crate manifest
├── src/
│   ├── lib.rs              # selenium__* FFI exports + ffi_call wrapper
│   ├── common.rs           # tokio runtime + session + element registries
│   ├── driver.rs           # open / quit / navigation / locator parsing
│   ├── element.rs          # find / wait_for / click / text / attr / ...
│   ├── script.rs           # execute_script / execute_async_script with WebElement arg unmarshaling
│   ├── actions.rs          # action-chain pointer/keyboard sequences (click / double / context / send_keys)
│   ├── capture.rs          # page + per-element screenshots
│   └── window.rs           # window rects / handles / new-window / frames / cookies
├── lib/Selenium.stk        # stryke wrappers (JSON args → FFI symbol → JSON return)
├── bin/selenium-test.stk   # installable smoke-test launcher
├── examples/               # runnable .stk demos
├── t/test_selenium.stk     # plumbing tests (permission-free FFI surface)
├── Makefile                # `make install` builds + installs
└── docs/                   # this site (GitHub Pages)

Sibling packages

Part of the stryke package family. Browse the others via the MenkeTechnologiesMeta umbrella repo:

• stryke-arrow — Apache Arrow / Parquet / Feather
• stryke-aws — S3, DynamoDB, SQS, Lambda, STS
• stryke-azure — Blob, Queues, Cosmos DB, Key Vault, Entra
• stryke-clickhouse — ClickHouse
• stryke-demo — live demos for every connector
• stryke-docker — Docker daemon API
• stryke-duckdb — embedded DuckDB SQL engine
• stryke-email — email + campaign client
• stryke-fleet — parallel expect/PTY automation
• stryke-gcp — Cloud Storage, Pub/Sub, Secret Manager, BigQuery, Firestore
• stryke-grpc — reflection-based gRPC client
• stryke-gui — mouse / keyboard / screen / clipboard automation
• stryke-k8s — Kubernetes
• stryke-kafka — Apache Kafka
• stryke-mcpd — MCP servers without a runtime
• stryke-mongo — MongoDB
• stryke-mssql — Microsoft SQL Server
• stryke-mysql — MySQL / MariaDB
• stryke-neo4j — Neo4j graph (Bolt)
• stryke-office — Office docs / PDF / images
• stryke-parquet — Parquet file inspector
• stryke-polars — Polars + ndarray + linalg + FFT
• stryke-postgres — PostgreSQL
• stryke-redis — Redis / Valkey
• stryke-scrape — web scraping / crawling
• stryke-scylla — ScyllaDB / Cassandra
• stryke-search — Elasticsearch / OpenSearch
• stryke-spark — Spark Connect (no JVM)
• stryke-utils — pure-stryke utility belt
• stryke-zmq — ZeroMQ messaging