WebDriver is a remote control interface that enables introspection and control of user agents. As such it can help developers to verify that their websites are working and performing well with all major browsers. The protocol is standardized by the W3C and consists of two separate specifications: WebDriver classic (HTTP) and the new WebDriver BiDi (Bi-Directional).

This newsletter gives an overview of the work we’ve done as part of the Firefox 118 release cycle.

Contributions

With Firefox being an open source project, we are grateful to get contributions from people outside of Mozilla:

• Rayyan refactored our navigation helpers to use a navigationId property instead of id
• Scott Ly updated our tests for exceptions to use appropriate assertion helpers

WebDriver code is written in JavaScript, Python, and Rust so any web developer can contribute! Read how to setup the work environment and check the list of mentored issues for Marionette and geckodriver.

General

Bug fixes

In Firefox 118, a bug was simultaneously fixed for WebDriver BiDi and Marionette:

• Both the WebDriver:PerformActions command in Marionette and the browsingContext.performActions command in WebDriver BiDi failed to correctly scroll for a wheel input source in environments that have a high-resolution display connected

WebDriver BiDi

Let’s have a look at our WebDriver BiDi updates for Firefox 118, with several improvements and additions to the browsingContext module.

New: “browsingContext.activate” command

Back in Firefox 117, we updated browsingContext.create to support a background argument and to open new contexts in the foreground by default. In this release we are adding the browsingContext.activate command which can move an existing tab to the foreground and focus its document. If the tab’s window was in the background, it will also be moved to the front.

New: “browsingContext.userPromptOpened” event

browsingContext.userPromptOpened is a new event which is emitted whenever a prompt of type “alert”, “confirm” or “prompt” is opened. The event’s payload contains the context where the dialog is displayed as well as the dialog’s type and message.

This event will also support "beforeunload" type dialogs in the future, but they are not handled at the moment.

New: “browsingContext.handleUserPrompt” command

User prompts created using window.alert, window.confirm or window.prompt can now be handled using the new browsingContext.handleUserPrompt command.

This command first takes a context argument, which corresponds to the tab displaying a prompt. Then you can provide an accept boolean to accept or decline dialogs of type "confirm" and "prompt", as well as a userText string to set the content for "prompt" types. “alert” type dialogs are simply dismissed regardless of the provided arguments. In case there is no prompt in that tab, a NoSuchAlertError error will be thrown.

At the moment, this command cannot handle "beforeunload" prompts, but this should be fixed in an upcoming release.

New: “type” field in the JSON payload

To easily differentiate JSON payloads coming from the remote end, all JSON payloads now include a "type" field which can either be "success" for a successful response to a command, "error" when an error was thrown while handling a command, and finally "event" for any event emitted.

Marionette (WebDriver classic)

Support for Web Authentication extension commands

Dana Keeler added support for all the Web Authentication extension commands, which allow users to authenticate themselves by Public Key Credentials.

Bug fixes

In Firefox 118, the following bug was fixed for Marionette while working on similar features for WebDriver BiDi:

• on Android, we fixed a race condition which could lead to return an empty user text for prompts