Interacting with page.getBy*non-existing element hangs instead of throwing

[kettanaito]

Describe the bug

When using userEvent + page.getBy* and providing a selector that doesn't exist on the page, the test hangs forever instead of throwing "Element by this selector not found".

Reproduction

Reproduction repository: https://github.com/kettanaito/vitest-locator-issue

Actual behavior

 FAIL   chromium  src/App.test.tsx > fills in the email field
Error: Test timed out in 15000ms.
If this is a long-running test, pass a timeout value as the last argument or configure it globally with "testTimeout".

System Info

System:
    OS: macOS 15.2
    CPU: (24) arm64 Apple M2 Ultra
    Memory: 90.80 GB / 128.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 22.13.0 - /usr/local/bin/node
    npm: 10.9.2 - /usr/local/bin/npm
    pnpm: 9.15.3 - /opt/homebrew/bin/pnpm
  Browsers:
    Chrome: 132.0.6834.83
    Safari: 18.2
  npmPackages:
    vitest: ^3.0.2 => 3.0.2

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.

[kettanaito]

In the light of actionTimeout change, I would strongly ask you to reconsider a better default. A test failing due to timeout and a test failing due to me trying to access an element that doesn't exist are two different debugging experiences. Perhaps, actionTimeout should be set to the suite's timeout and throw first, before the generic timeout error.

[hi-ogawa]

I think this is important and playwright seems to deal with this dilemma somehow (assertion timeout vs. test timeout).

One idea I found in playwright is that, for the assertions expect.poll() and expect().toPass(), they adjust timeout dynamically based on remaining test time:

• chore: show last poller error on test timeout microsoft/playwright#24292
• chore: give more time to polling matchers to print friendly error microsoft/playwright#26595

But, as seen in the above PR, they are technically bending a genuine test timeout by subtracting some magic value. One interesting artifact is that, this allows try/catch-ing "test" timeout error.

For their page API (e.g. page.waitForTimeout()) and locator timeout logic, I'm guessing they have a similar idea, but I couldn't figure it out yet.