fix(browser): not.toBeInTheDocument works with locators API

[sheremet-va]

Description

Related #6560

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

Name	Link
🔨 Latest commit	10e081a
🔍 Latest deploy log	https://app.netlify.com/sites/vitest-dev/deploys/66feaa04743fa20008faa38d
😎 Deploy Preview	https://deploy-preview-6634--vitest-dev.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.

[hi-ogawa]

Chai flag approach is very clever, but is it necessary to support this use case?
From the discussion #6560, I feel it would also make sense to emphasize the difference between element and query like jest-dom instead of special casing toBeInTheDocument.

I'm sure if I'm missing some nuance, but by discussion OP's argument, I would be probably equally surprised if this happens:

// this pass
await expect.element(page.getByText('empty')).not.toBeInTheDocument()

// but this throws
await expect.element(page.getByText('empty')).not.toBeVisible()

Clarifying expect.element's behavior and being consistent sounds better to me to confusion.

[sheremet-va]

Clarifying expect.element's behavior and being consistent sounds better to me to confusion.

Even if we just clarify how it works, there is no way to assert that the element is not in the DOM with expect.element.

not.toBeInTheDocument is a known convention in testing-library, so that's why I am prioritizing it here

await expect.element(page.getByText('empty')).not.toBeVisible()

This is a bit of a different story because it requires the change to the query itself, not the the way we retrieve the element:

- await expect.element(page.getByText('empty')).not.toBeVisible()
+ await expect.element(page.getByText('empty', { force: true })).not.toBeVisible()

So this would require a different change to work if we want to have a built-in support.

[hi-ogawa]

Even if we just clarify how it works, there is no way to assert that the element is not in the DOM with expect.element.

not.toBeInTheDocument is a known convention in testing-library, so that's why I am prioritizing it here

Okay, sounds good. expect.element expecting Element seemed simpler mental model, but I guess it's worth having this.