[BUG] Emulation of locale doesn't affect the "accept-language" request header value in WebSocket connection on chromium browsers. #13919

Context:

• Playwright Version: 1.21.1
• Operating System: Windows 11 Pro x64 21H2 Build 22000.652
• Node.js version: v16.14.0
• Browser: Chromium

System:

• OS: Windows 10 10.0.22000
• Memory: 5.63 GB / 15.84 GB

Binaries:

• Node: 16.14.0 - C:\Program Files\nodejs\node.EXE
• npm: 8.3.1 - C:\Program Files\nodejs\npm.CMD

The sample code and the step to reproduce the problem

First, extract the following zip file I attached into a working directory.

📦express-ws-app-and-playwright-locale-test.zip

The "playwright.config.ts" contained in that zip file is below.

// playwright.config.ts
import { devices } from "@playwright/test"

const config: any = {
    use: {
        headless: false,
        locale: 'fr-FR',  // 👈 Emulate locale to "fr-FR".
    },
    projects: [
        {
            name: 'chrome',
            use: { ...devices['Desktop Chrome'], channel: 'chrome' },
        },
        {
            name: 'msedge',
            use: { ...devices['Desktop Edge'], channel: 'msedge' },
        },
        {
            name: 'firefox',
            use: { ...devices['Desktop Firefox'] },
        },
    ]
};
export default config;

This configuration means to emulate the browser locale to the "fr-FR".

Next, on the working directory, execute the following commands in a terminal console.

$ npm install
$ npm start

And on the same working directory, execute the following commands in another terminal console.

$ npm test

Describe the bug

After executing the above commands, you can see the "accept-language" HTTP request header value is "fr-FR" as I expected.

But unexpectedly, the "accept-language" request header value in the WebSocket connection is not "fr-FR" but the browser's default locale.

That unexpected behavior can be reproduced only chromium browsers such as chrome and msedge.

In case of Firefox doesn't look having this problem.
On a Firefox browser, the "accept-language" request header value in the WebSocket connection is also changed to one that I expected.

In addition, in the case of using Selenium and its WebDriver and doing the same test emulating locale, this problem doesn't happen even on chromium browsers.