Files

T

Devin Rousso a043907285 Bug 2052932 - [webdriver-bidi] emulation.setLocaleOverride does not override Accept-Language header for in Worker for fetch and WebSocket r=necko-reviewers,kershaw,jdescottes,whimboo

Bug 1995691 made `emulation.setLocaleOverride` override the `Accept-Language` request header, but only for document-initiated requests.
Bug 2015655 made the locale override apply to the JS realm and `navigator.language` in `Worker` and `SharedWorker` but it did not touch the `Accept-Language` header or `WebSocket` path.

`HttpBaseChannel::Init` already applies the override centrally (via `AddStandardRequestHeaders`) from the loading `BrowsingContext`'s locale override, but `Worker` requests have no loading `BrowsingContext` so it never fired for them. `Init` now falls back to the associated `BrowsingContext` when the loading one is `null`.

For that fallback to work, the associated `BrowsingContext` has to be on the `LoadInfo` before the channel runs `Init`:
- `fetch()` now threads the associated `BrowsingContext` id through channel creation so it is set while the `LoadInfo` is constructed, instead of afterwards once the channel (and its request headers) already exist.
- The `WebSocket` handshake now reuses the `WebSocket`'s own `LoadInfo` (which already carries the association) via a new `nsIIOService::newChannelFromURIWithProxyFlagsAndLoadInfo`, rather than synthesizing a fresh `LoadInfo` that dropped it.

Leaning on the central path lets both manual `Accept-Language` `SetRequestHeader` blocks go away, and also covers `Worker` `XMLHttpRequest` for free.

Differential Revision: https://phabricator.services.mozilla.com/D310690

2026-07-14 05:41:57 +00:00

tests

Bug 2052932 - [webdriver-bidi] emulation.setLocaleOverride does not override Accept-Language header for in Worker for fetch and WebSocket r=necko-reviewers,kershaw,jdescottes,whimboo

2026-07-14 05:41:57 +00:00

META.yml

…

README.md

…

README.md

WebDriver specification tests

Herein lies a set of conformance tests for the W3C web browser automation specification known as WebDriver. The purpose of these tests is determine implementation compliance so that different driver implementations can determine whether they meet the recognized standard.

Chapters of the Spec that still need tests

We are using a tracking spreadsheet to coordinate work on these tests. Please look there to see who is working on what, and which areas are currently under-tested.

The spec contributors and editors can frequently be found on the W3C #webdriver IRC channel.