fix(browser): fix browser testing url for https

[hi-ogawa]

Description

Closes #4844

I used ViteDevServer.resolvedUrls to grab the url for browser testing. I think this should be always available and If this is not available, then it's probably a Vite bug, so I didn't put any fallback or validation here.

On a related note, currently Vite's base config is not supported yet (as reported in #4686), but ViteDevServer.resolvedUrls will be also generated according to base config, so I think treating resolvedUrls as a single source of truth is appropriate for browser testing.
(Actually base doesn't change browser testing url since it's always root /, but I guess it would still make sense to use resolvedUrls as a way to get origin.)

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
• Ideally, include a test that fails without this PR but passes with it.
• Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.

Tests

• Run the tests with pnpm test:ci.

Documentation

• If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

• Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.

[netlify]

✅ Deploy Preview for fastidious-cascaron-4ded94 canceled.

Name	Link
🔨 Latest commit	ba594a4
🔍 Latest deploy log	https://app.netlify.com/sites/fastidious-cascaron-4ded94/deploys/65a6284a38df8d0008e2fc98

[hi-ogawa]

Similar to the above test job, I thought it's better to run all matrix without fail-fast so that it's easier to identify potential browser-specific quirks.

[hi-ogawa]

As commented in #4879 (comment), I found that webkit flakiness is related to Vite pre-bundling somehow. For now, separating vite cacheDir can workaround the issue, so I added this here.

To verify this, I repeated pnpm run test:browser:playwright 20 times consecutively on CI and it didn't fail https://github.com/vitest-dev/vitest/actions/runs/7454247103/job/20281233631#step:11:1

I'm still not sure the same issue could be reproduced outside of Vitest since this issue might be related to Vitest being a linked dep for this in-repository tests.

[sheremet-va]

There is a possibility that this might be null if server is restarted (due to a config change): vitejs/vite#15450

Does it affect us?

[hi-ogawa]

Thanks for the reference. There could be something sketchy scenario. I'll look into it.

Also another thing, actually it might not be preferred to use resolveUrls since it looks like Vite has some inconsistency when users set vite config like server.host: "local.example.com".

• Port 443 doesn't work (i.e. https://local.example.com/ does not work) vitejs/vite#11342
• read certificate and show the correct domain when startup vitejs/vite#8200

Let me think about it.

[hi-ogawa]

I just remembered this issue about Vite's --open default behavior:

• Server.open can not be opened with default Network url vitejs/vite#14921 (comment)

Essentially Vite does a following when ViteDevServer.openBrowser:

new URL(options.open, resolvedUrls.local[0] ?? resolvedUrls.network[0])

https://github.com/vitejs/vite/blob/2687dbbd4e19c86f9888ee784c9b51598e8b79ca/packages/vite/src/node/server/index.ts#L484-L492

This also means that provider: "none" is already forcing url origin to be resolvedUrls.local[0] ?? resolvedUrls.network[0], so aligning this behavior for all providers should not be that bad.
(Ah, actually that's not the case. new URL(x, y) doesn't change origin to y if x already includes origin.)

[hi-ogawa]

Regarding Vite server's restart behavior, I don't think that's relevant for Vitest browser mode since browser mode uses a dedicated Vite dev server, which doesn't watch files on its own and is completely re-spawned when Vitest's main server restarts:

vitest/packages/vitest/src/integrations/browser/server.ts

Lines 21 to 27 in b2c79e4

	// watch is handled by Vitest
	server: {
	hmr: false,
	watch: {
	ignored: ['**/**'],
	},
	},

vitest/packages/vitest/src/node/workspace.ts

Lines 271 to 276 in b2c79e4

	async initBrowserServer(configFile: string | undefined) {
	if (!this.isBrowserEnabled())
	return
	await this.browser?.close()
	this.browser = await createBrowserServer(this, configFile)
	}

So, relying on resolvedUrls should be safe before landing vitejs/vite#15450 in Vite v5.1.

Currently the log looks like this for playwright provider:

Restarting due to config changes...

 DEV  v1.2.0 /home/hiroshi/code/others/vitest/test/browser/fixtures/server-url
      Browser runner started at http://localhost:5174/

But webdriverio actually doesn't support restart at all since it kills a whole process when Vitest main server tries to restart and close all existing pools:

vitest/packages/vitest/src/node/core.ts

Line 88 in b2c79e4

this.pool?.close?.()

vitest/packages/browser/src/node/providers/webdriver.ts

Lines 93 to 95 in b2c79e4

	// TODO: right now process can only exit with timeout, if we use browser
	// needs investigating
	process.exit()