Webs_webdriver (webs.Webs

Webdriver

module Wd : sig ... end

Webdriver connections and commonalities.

module Wd_session : sig ... end

Session module.

module Wd_browser : sig ... end

Browser module.

module Wd_browsing_context : sig ... end

module Wd_emulation : sig ... end

module Wd_network : sig ... end

Network module.

module Wd_script : sig ... end

Script module.

module Wd_storage : sig ... end

Storage module.

module Wd_log : sig ... end

Log module.

module Wd_input : sig ... end

Input module.

module Wd_web_extension : sig ... end

Based on the 2026-05-11 specification, may need adjustements in the future, it seems no diffs are published :-( Also in case of problems consult the browser implementation status, not everything is implemented.
32-bit platforms. The representation of the specification's integer and unsigned integers by OCaml int values may quickly overflow on 32-bit platforms. Errors are reported but that may hamper using the module on these platforms.
Extensions. In general our descriptions using Jsont types do not error on unknown members. Sometimes these are surfaced as Wd.Exts types but not always, especially if not indicated in the specification.
Low-level. The interface is purposedly low-level and matches what the protocol offers. Nicer abstractions should be built on top of this.

Add a driver configuration option to redirect std outputs of spawn
Add a driver discovery function or make the driver argument optional in Webs_webdriver.Wd.Connection.
The driver spawn story is still a bit shady. Only FF is well defined for now, but it's already one browser we can use for end-to-end testing.
Concurrency story.
Adjust the event processing story. It's nice not to have direct style but the current scheme is too racy. Since subscription is explicit we could record the subscriptions and buffer those events who match them in a ring buffer. If we don't want to meddle with subscriptions we could perhaps have await [`Next | `Step] to indicate with `Step indicating we are interested in awaiting future events. Though meddling with subscriptions could allow to dicontinue awaits on unsubscribe.
The documentation both points into MDN and the spec which is a bit annoying. Very little is however documented on MDN should we only point on the spec (which is dry to the extreme)?
Get rid of More? Bof, it's already a lot of code (boilerplate though), not keen on adding more
A few internal cleanups if we get this in jsont. Search the codebase for that URL.
Make a nicer high-level API for webapp snapshot end-to-end testing. But in a separate library.
Explain event processing, mention the drop log
Add a simple example