[Regression]: http:// navigations are upgraded to https:// in Chromium 158, Chrome and Edge #43871

Last Good Version

1.64.1

First Bad Version

1.65.0-next. Two changes cause this:

• chore(chromium): stop disabling the HttpsUpgrades feature #43455 stops disabling HttpsUpgrades. This affects Google Chrome and Microsoft Edge.
• feat(chromium): roll to r1253 #43778 rolls to Chromium 158, which enables HTTPS-First balanced mode by default (HttpsFirstBalancedModeAutoEnable). This affects the bundled Chromium.

Steps to reproduce

Neither script needs an external site.

A host that has only http:

const http = require('http');
const { chromium } = require('playwright');

(async () => {
  const server = http.createServer((req, res) => res.end('served over http'));
  await new Promise(resolve => server.listen(0, '127.0.0.1', resolve));
  const { port } = server.address();

  const browser = await chromium.launch({
    channel: 'chromium',
    args: [`--host-resolver-rules=MAP staging.example.org:80 127.0.0.1:${port},MAP staging.example.org:443 127.0.0.1:9`],
  });
  const page = await browser.newPage();
  await page.goto('http://staging.example.org/');
  console.log(page.url());
  await browser.close();
  server.close();
})();

A mock of an http:// URL:

const { chromium } = require('playwright');

(async () => {
  const browser = await chromium.launch({ channel: 'chrome' });
  const page = await browser.newPage();
  await page.route('http://app.example.org/', route => route.fulfill({ contentType: 'text/html', body: 'mocked' }));
  await page.goto('http://app.example.org/');
  console.log(await page.textContent('body'));
  await browser.close();
})();

Expected behavior

Playwright has disabled HTTPS upgrades since 2023 (#27605), so users expect the following:

• page.goto('http://...') opens that URL, and page.url() and toHaveURL() report it.
• page.route() for an http:// URL receives the request. The mocked host does not have to exist.
• One navigation makes one navigation request. page.on('request'), HAR files and proxy logs show only that request.
• A test gives the same result headless and headed. A developer can run --headed or --debug to investigate a failure from CI.

Actual behavior

The first script fails with page.goto: net::ERR_BLOCKED_BY_CLIENT at http://staging.example.org/. The error does not say that an HTTPS upgrade is the cause.

The second script fails with page.goto: net::ERR_NAME_NOT_RESOLVED at http://app.example.org/, because the request goes to https:// and the route does not match.

Requests are navigation requests seen by page.on('request'). Tested on Linux with 8195aab, Chromium 158.0.8127.2, Chrome 156.0.8078.47 and Edge 155.0.4283.62.

Who is affected

• Headed runs and new headless: --headed, --debug and channel: 'chromium'. The default headless shell does not have this feature, so a test can pass on CI and fail when a developer runs it headed.
• Chrome and Edge: channel: 'chrome' and channel: 'msedge'. This includes Playwright MCP, which uses the chrome channel by default.
• Common setups: staging hosts on port 80 with a public-looking name, tests that mock http:// URLs, and HTTP proxies.

Our test suite did not detect this, because localhost, private IP addresses and non-default ports are never upgraded. #43454 changed the proxy tests to use an exempt host name. Users would have to make the same change to their tests.

This does not affect only 1.65

Disabling HttpsUpgrades alone has no effect on Chromium 158. Playwright 1.64.1 with the Chromium 158 build (r1253) gives net::ERR_BLOCKED_BY_CLIENT in the same scenarios.

Chrome 158 is scheduled for early stable on 2026-11-04 and stable on 2026-11-17. I expect channel: 'chrome' and Playwright MCP to fail on these dates with every current Playwright version. I tested with the Chromium 158 build, because Chrome 158 stable is not available yet.

Users cannot safely work around this

The workaround from #43455 is args: ['--disable-features=HttpsUpgrades,HttpsFirstBalancedModeAutoEnable']. Chromium uses only the last --disable-features flag, so this replaces the list that Playwright passes, including ThirdPartyStoragePartitioning and PaintHolding. I confirmed this by passing the flag twice: only the last one had an effect. A safe workaround must repeat the full Playwright list, which changes between versions.

Recommendation for 1.65

Disabling both features gave the 1.64.1 result in every scenario above, on headed Chromium 158, the chromium channel, Chrome 156 and Edge 155. I tested this by passing the full default list plus the two features.

Recommended steps:

1. Before we cut release-1.65, add HttpsUpgrades and HttpsFirstBalancedModeAutoEnable to disabledFeatures in packages/playwright-core/src/server/chromium/chromiumSwitches.ts. This reverts chore(chromium): stop disabling the HttpsUpgrades feature #43455.
2. Add a regression test that navigates to a public-looking host name through --host-resolver-rules, because localhost is exempt. Run it on headed Chromium, the chromium channel and the chrome channel. Chromium can remove or rename these features, and this test will then fail on the next roll.
3. Remove the HTTPS upgrade item from the 1.65 breaking changes.
4. Release 1.65 before Chrome 158 stable on 2026-11-17, and consider a 1.64 patch release with the same change.
5. If we want real browser behavior later, add it as an explicit option with its own announcement. It should not come as a side effect of a Chromium roll.