window.location.pathname contains test metadata when Browser mode is enabled

[bteng22]

Describe the bug

My team is trying to migrate our tests from Web Test Runner to Vitest and we have a few tests that are failing due to window.location.pathname. We have Vitest's Browser Mode enabled and noticed it places test metadata onto our path, which I'm assuming is from:

vitest/packages/browser/src/client/orchestrator.ts

Lines 94 to 99 in c82387d

	iframe.setAttribute(
	'src',
	`${url.pathname}__vitest_test__/__test__/${
	getBrowserState().sessionId
	}/${encodeURIComponent(file)}`,
	)

.

Unfortunately, there's cases in our application code that expect window.location.pathname to be specific routes e.g.

    const path = window.location.pathname
    const isHomePagePath = path === '/' || path === '/home'

But our pathname when running our tests results is something similar to: "/__vitest_test__/__test__/2650bfc6-b49a-4c09-868f-44fa8a52c2ae/%2Fpath%2Fto%2Ftest%2Ffile.ts",

Any workarounds or suggestions here since we're not able to mock/redefine window.location? Hoping not to modify our application code and keep this isolated to our tests. Or is Vitest able to implement something similar to what Web Test Runner does? It saves the metadata onto a namespaced variable on the global window.

e.g.
window.__WTR_CONFIG__ = {"testFile":"/name/of/test/file.ts?wtr-session-id=HzIg-c9rnYcBvBOdTLkT4","watch":false,"debug":false,"testFrameworkConfig":{"timeout":10000,"retries":1}}

Reproduction

https://stackblitz.com/edit/vitest-dev-vitest-r7td449n?file=test%2Fone.browser.test.ts

System Info

System:
    OS: Linux 5.0 undefined
    CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 0 Bytes / 0 Bytes
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 18.20.3 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.2.3 - /usr/local/bin/npm
    pnpm: 8.15.6 - /usr/local/bin/pnpm
  npmPackages:
    @vitest/browser: 3.0.4 => 3.0.4 
    playwright: 1.35.0 => 1.35.0 
    vite: 6.0.9 => 6.0.9 
    vitest: 3.0.4 => 3.0.4

Used Package Manager

npm

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[hi-ogawa]

I think window.location global is somewhat sacred due to the way Vitest browser mode works (browser/iframe needs to navigates to that special page), but maybe we can explore allow mocking window.location on user code by the similar technique as process.env mocking for #6667.

[bteng22]

Thanks @hi-ogawa some kind of mocking or control over window.location would be really helpful here! We're being forced to make checks like !window.__vitest_browser__ in our application code so we can avoid pathing issues mentioned above. If there's anyway we can temporarily obscure this Vitest metadata from the pathname it'd be helpful

[hi-ogawa]

@bteng22 Can you explain what you would do on Web Test Runner? Do you simply want window.location.pathname to always return some constant value like / or do you also need to simulate navigation by writing window.location.href?

If you only need to patch how window.location is read, you may try a plugin like this https://stackblitz.com/edit/vitest-dev-vitest-xjxwdm7a?file=vite.config.ts

// config
  plugins: [
    {
      name: 'hack',
      transform(code, id) {
        if (
          !id.includes('/node_modules/') &&
          code.includes('window.location')
        ) {
          return code.replaceAll('window.location', `__MOCK_LOCATION__`);
        }
      },
    },
  ],

// test
vi.stubGlobal('__MOCK_LOCATION__', {
  pathname: '/mocked',
});

test('window.location.pathname should not be polluted?', () => {
  console.log(window.location.pathname);
  expect(window.location.pathname).toBe('/mocked');
});

[bteng22]

@hi-ogawa For now we just need window.location.pathname to return some constant value. On Web Test Runner the window.location.pathname is already set to / but it uses the query parameters to attach test metadata.

I'll give the plugin a shot! Thanks for the suggestion.

[sheremet-va]

In the next version Vitest keeps IDs in queries. See PR: #7665

The URL though still starts with /__vitest_test__/__test__. For example, /__vitest_test__/__test__?sessionId=123&iframeId=123

[silvenon]

On this note, is it safe to rely on window.__vitest_browser__ in our implementation code to make a distinction that we're running in Browser Mode, and not unit tests with jsdom/happy-dom? It sounds very internal.

My component relies of the value of window.location.href, so I'd like to update it to rely on another value instead that I set in my tests (which I know is not ideal, but it's the best compromise I could think of).

Or do you recommend that we define a import.meta.env.BROWSER_MODE or something like that in our test configuration? With a matching definition in our non-test config that would replace it with false.

[sheremet-va]

On this note, is it safe to rely on window.__vitest_browser__ in our implementation code to make a distinction that we're running in Browser Mode, and not unit tests with jsdom/happy-dom? It sounds very internal.

My component relies of the value of window.location.href, so I'd like to update it to rely on another value instead that I set in my tests (which I know is not ideal, but it's the best compromise I could think of).

Or do you recommend that we define a import.meta.env.BROWSER_MODE or something like that in our test configuration? With a matching definition in our non-test config that would replace it with false.

You can use expect.getState().environment to distinct different environments

[silvenon]

This sounds like a test-only way to make the distinction, and within the test I already know what the mode is. I was talking about the implementation code, where, for example, import.meta.env.MODE allows me to know that I'm testing, but not sure if it's unit or browser mode.

I guess typeof process === 'undefined' could be one way 🤔 although that won't get removed when bundling for production because it won't get replaced. Also, doesn't seem future-proof, what if window.process eventually exists, who knows.

Anyway, I settled on import.meta.env.VITEST_BROWSER_MODE + window.__TEST_LOCATION_HREF__, for now it's working fine for my use case.

Code

// vite.config.ts
{
  define: {
    'import.meta.env.VITEST_BROWSER_MODE': JSON.stringify(false),
  },
  test: {
    workspace: [
      // other projects
      {
        extends: true,
        define: {
          'import.meta.env.VITEST_BROWSER_MODE': JSON.stringify(true),
        },
        test: {
          name: 'browser',
          // config for browser mode project
        },
      },
    ],
  },
}

// tests
beforeEach(() => {
  window.__TEST_LOCATION_HREF__ = 'https://default-example.com/'
})
test('whatever', () => {
  // this way I can set location.href per-test, which is what I needed
  window.__TEST_LOCATION_HREF__ = 'https://example.com/'
  render(<MyComponent />)
  // assertions
})

// implementation code
let locationHref = window.location.href
if (import.meta.env.VITEST_BROWSER_MODE) {
  locationHref = window.__TEST_LOCATION_HREF__
}
// do something with "locationHref"

[sheremet-va]

This is fixed by #8126

The pathname is / by default.