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

Contributions

Firefox – including our WebDriver implementation – is developed as an open source project, and everyone is welcome to contribute. 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, jump in.

We are always grateful to receive external contributions, here are the ones which made it in Firefox 131:

• Dan (temidayoazeez032) added a base RootBiDiModule class and an emitEventForBrowsingContext method in it to make it easier to share the code between the WebDriver BiDi root modules.

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.

General

Bug fixes

• For both WebDriver Classic and BiDi the "keyUp” and "keyDown" actions will no longer accept multiple characters for the "value". These actions are now limited to a single grapheme cluster to ensure consistent behavior.

WebDriver BiDi

New: Add support for remaining arguments of “network.continueResponse”

In Firefox 131 we added support for the remaining arguments of the "network.continueResponse" command, such as cookies, headers, statusCode and reasonPhrase. This allows clients to modify cookies, headers, status codes (e.g., 200, 304), and status text (e.g., “OK”, “Not modified”) during the "responseStarted" phase, when a real network response is intercepted, while preserving the response body.

-> {
  "method": "network.continueResponse",
  "params": {
    "request": "12",
    "headers": [
      { 
        "name": "test-header", 
        "value": { 
          "type": "string", 
          "value": "42"
        }
      }
    ],
    "reasonPhrase": "custom status text",
    "statusCode": 404
  },
  "id": 2
}

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

Bug fixes

• The "browsingContext.navigate" command will now return if the "wait" argument is "none" and a beforeunload prompt is triggered.
• The "browsingContext.navigate" command will now return an "unknown error" in all cases where a navigation failure occurs, as required by the specification.
• The "session.new" command will no longer include the "unhandledPromptBehavior" capability in its response if it was not specified by the client as an argument.