feat(browser): run test files in isolated iframes

[sheremet-va]

Description

This PR changes how Vitest runs browser tests internally. This is a successor to #3584, but without any visuals.

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 ready!

Name	Link
🔨 Latest commit	dedaea8
🔍 Latest deploy log	https://app.netlify.com/sites/fastidious-cascaron-4ded94/deploys/65c22c1d3371e300080a716b
😎 Deploy Preview	https://deploy-preview-5036--fastidious-cascaron-4ded94.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[sheremet-va]

@userquin @Aslemammad I don't really like that we run all tests in parallel - this makes it impossible to use keyboard events for example. Should we default to running tests one after another?

[userquin]

@userquin @Aslemammad I don't really like that we run all tests in parallel - this makes it impossible to use keyboard events for example. Should we default to running tests one after another?

What do you mean about using keyboard events? related to this issue #4918?

IIRC you cannot simulateTab key since we cannot override isTrusted (set to true by the browser when the user press the tab key), we should add some helper.

[sheremet-va]

What do you mean about using keyboard events? related to this issue #4918?

Yes, look into the open PR. (I didn't test it yet, it's just a drafter POC). But the idea is that we need to have an element with a focus but if we run tests in parallel the focus can shift between iframes and elements at any time.

[userquin]

What do you mean about using keyboard events? related to this issue #4918?

Yes, look into the open PR. (I didn't test it yet, it's just a drafter POC). But the idea is that we need to have an element with a focus but if we run tests in parallel the focus can shift between iframes and elements at any time.

I think there is no need, using none provider I have 2 tests files using focus and working: ofc if we have multiple focus tests in the same file the problem will be there.

Add "test-ui": "PROVIDER=none vitest" (or run it from your terminal, I'm using Windows...) to test/browser/package.json and add the following test to test/browser/test/another.test.ts and test/browser/test/basic.test.ts:

it('test focus', async () => {
  const host2 = document.createElement('div')
  host2.setAttribute('id', 'host2')
  document.body.appendChild(host2)
  const btn1 = document.createElement('button')
  btn1.innerHTML = 'Click me 1'
  btn1.addEventListener('keydown', (e) => {
    console.log(e)
  })
  btn1.addEventListener('keyup', (e) => {
    console.log(e)
  })
  host2.appendChild(btn1)
  const btn2 = document.createElement('button')
  btn2.innerHTML = 'Click me 2'
  host2.appendChild(btn2)
  expect(document.activeElement).toBe(document.body)
  btn1.focus()
  expect(document.activeElement).toBe(btn1)
  btn2.focus()
  expect(document.activeElement).toBe(btn2)
  btn1.focus()
  expect(document.activeElement).toBe(btn1)
  await new Promise(resolve => setTimeout(resolve, 100))
  btn1.dispatchEvent(new KeyboardEvent('keydown', { key: 'Tab' }))
  btn1.dispatchEvent(new KeyboardEvent('keyup', { key: 'Tab' }))
  /* btn1.dispatchEvent(new KeyboardEvent('keypress', {
    key: 'Tab',
    view: window,
    bubbles: true,
    cancelable: true,
    /!* code: 'Tab',
    isComposing: true,
    charCode: 0,
    keyCode: 9,
    which: 9,
    composed: true,
    location: 0,
    view: window,
    bubbles: true,
    cancelable: true,
    shiftKey: false,
    ctrlKey: false,
    altKey: false,
    metaKey: false, *!/
  })) */
  await new Promise(resolve => setTimeout(resolve, 100))
  console.log(document.activeElement)
  // THIS WILL FAIL
  // expect(document.activeElement).toBe(btn2)
})

[sheremet-va]

I think there is no need, using none provider I have 2 tests files using focus and working: ofc if we have multiple focus tests in the same file the problem will be there.

There is a great need for that. Dispatching keyboard event doesn't work the same way as the user would do it. In the real world, the keyboard triggers multiple events and it is not possible to emulate the order of it down to the microtask in the browser (just like the click), so we need to do it through a webdriver API or google devtools API.

Add "test-ui": "PROVIDER=none vitest" (or run it from your terminal, I'm using Windows...) to test/browser/package.json and add the following test to test/browser/test/another.test.ts and test/browser/test/basic.test.ts:

none provider is outside of this PR's responsibility and doesn't support the same set of APIs - if users want to "emulate" clicks and keyboard events they can just use jsdom (or libraries like fire-event) - all of them don't actually test what is happening in the real scenario.

[userquin]

Once the tests finish, the focus will be on the last focus test (when opening/focusing the browser).