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 128 release cycle.

Contributions

Firefox – including our WebDriver implementation – is developed as an open source project, and everyone is welcome to contribute. There were no external contributions during the Firefox 128 release cycle, but I’m sure we will have more in the next cycles. If you ever wanted to contribute to an open source project used by millions of users, or are interested in some experience in software development, we have many beginner-friendly available over at https://codetribute.mozilla.org/.

General

Support for the extended “unhandledPromptBehavior” capability

We now support the extended “unhandledPromptBehavior” capability which can either be a string (for WebDriver Classic) or a JSON object (for WebDriver BiDi). The JSON object can be used to configure a different behavior depending on the prompt type, which is useful for instance to handle “beforeunload” prompts.

{
  "unhandledPromptBehavior": {
    "default": "accept and notify",
    "beforeUnload": "accept"
  }
}

WebDriver BiDi

Support for the “BiDi flag”

We now support the “BiDi flag” of a WebDriver Session to align with the WebDriver BiDi specification. This allows to identify sessions created for or upgraded to WebDriver BiDi.

Support for several arguments for the `network.continueRequest` command

In previous releases, we introduced commands to intercept and resume requests, such as network.addIntercept and network.continueRequest. With Firefox 128 we now support most of the optional parameters for network.continueRequest, which means you can now modify requests blocked in the beforeRequestSent phase. The available parameters are body, cookies, headers and method. The modification will happen before the request is sent to the server, so this can be used for instance to add some test-specific headers to certain requests.

-> {
  "method": "network.continueRequest",
  "params": {
    "request": "12",
    "headers": [
      { 
        "name": "test-header", 
        "value": { 
          "type": "string", 
          "value": "42"
        }
      }
    ]
  },
  "id": 2
}

<- { "type": "success", "id": 2, "result": {} }

Take a look at the specification to learn more about the types for the new parameters. There is still one parameter to implement for network.continueRequest which is url and will allow to redirect a request to another URL, hopefully coming soon.

Also note that before Firefox 128, the requests blocked in the beforeRequestSent phase could still intermittently be blocked a bit late and reach the server. This should now be fixed, and requests blocked in this phase should not reach the network until resumed.

Support for the `userContext` argument in the `permissions.setPermission` command

We now support the userContext argument for permissions.setPermission, which allows to isolate a specific permission update to a single user context (Firefox Container). userContext is expected to be a string corresponding to the id of a user context.

Bug fixes

• Fixed a bug in `browsingContext.navigate` where a navigation error would load an error page and cause subsequent commands to fail.
• Fixed the order in which `network.responseCompleted` events are emitted for redirects. The original request’s responseCompleted is now always emitted before the events for the redirect.
• Introduced a workaround to not partition cookies which are added with the “storage.setCookie” command for the same domain as the page loaded in the targeted context. This aligns with the current behavior of Firefox, and will be updated as support for CHIPS in Firefox progresses.
• The input.setFiles command has been updated to throw an UnsupportedOperation error if the specified file does not exist.

Marionette (WebDriver classic)

Support for the “http flag”

Similar to the “BiDi flag”, we also added support for the “HTTP flag” of a WebDriver Session. This allows to identify sessions created for WebDriver classic.

Support for the Permissions API in WebDriver Classic

Following the work in WebDriver BiDi in previous releases, we added support for the Permissions commands in WebDriver Classic.