[Bug]: Clock mocking impacting page click events

[EwenDC]

Version

1.45.3

Steps to reproduce

1. Clone the repository at https://github.com/EwenDC/Playwright-Clock-Bug
2. Execute the command npm install
3. Run the two included Playwright tests using the npm test command.

Expected behavior

The test "works without mock clock" should pass, and the test "fails with mock clock" should fail, as the only difference between the two tests is the use of page.clock (which should have no effect on the functionality of this demo app)

Actual behavior

Both tests pass, as when the mocked clock is installed and time is fast forwarded, the select list within the dialog stops receiving click events.

Additional context

This is a minimal reproduction based off a legacy Vue 2 application maintained at our company. We recently decided to use page.clock to speed up our end-to-end tests by allowing us to skip minutes of idle time waiting for frontend polling events. However, once we added page.clock to our tests, some of our tests started failing for reasons unrelated to the polling.

Namely, we had a test involving verifying the values shown in a select list within a dialog. Before adding a clock.fastForward call, this test worked fine. However, after adding the clock.fastForward call, the select list became totally unresponsive to click events. We also sporadically observed this behaviour in other parts of the UI (even before clock.fastForward was called), namely in icon buttons with tooltips. These buttons would fail to register clicks if you clicked directly on the icon, but would still register clicks against the button whitespace. I have included both listed scenarios in the reproduction, but unfortunately I was not able to get the failed icon button click to reliably trigger.

We observed these scenarios both within test executions, and when manually interacting with the test browsers in debug mode. Interestingly, I observed that when using debug mode, it was possible to get the select list to work by calling .click() on the <div> with the class el-input that surrounds the <input> element. This leads me to believe the root cause of this issue is page events not properly propagating when page.clock is in use, though I have no idea why that would be the case.

Environment

System:
    OS: macOS 14.5
    CPU: (8) arm64 Apple M1 Pro
    Memory: 177.72 MB / 32.00 GB
  Binaries:
    Node: 20.14.0 - ~/.nvm/versions/node/v20.14.0/bin/node
    npm: 10.7.0 - ~/.nvm/versions/node/v20.14.0/bin/npm
  Languages:
    Bash: 3.2.57 - /bin/bash
  npmPackages:
    @playwright/test: 1.45.3 => 1.45.3

[pravintargaryen]

I get the following error while trying to reproduce

[EwenDC]

Can you try manually hosting the dev server with npm run dev? I set playwright to do it automatically but it might not have worked for you.

[mxschmitt]

I can reproduce. Seems related to our performance.now() impl inside our clock. If we don't mock it, it works. Vue.js scheduler seems to use it. We'll take a look.

[pravintargaryen]

@EwenDC @mxschmitt will follow your methods

[cooper667]

Not sure the fix works for this?

Steps to reproduce
Clone the repository at https://github.com/EwenDC/Playwright-Clock-Bug
npm i
npm i playwright@next
npm test

Still fails with @playwright/test@1.47.0-alpha-2024-08-19

[mxschmitt]

works for me, I think because you are not installing the latest @playwright/test and playwright instead. Try to follow this guide: https://playwright.dev/docs/canary-releases

[cooper667]

18:09:22 ~/projects/Playwright-Clock-Bug (main) $ npm run test -- --version

> playwright-clock-bug@0.0.0 test
> playwright test --version

Version 1.47.0-alpha-2024-08-19
18:09:28 ~/projects/Playwright-Clock-Bug (main) $ npm list --depth=5 | grep playwright
playwright-clock-bug@0.0.0 /Users/cooper667/projects/Playwright-Clock-Bug
├─┬ @playwright/test@1.47.0-alpha-2024-08-19
│ └── playwright@1.47.0-alpha-2024-08-19 deduped
├─┬ playwright@1.47.0-alpha-2024-08-19
│ └── playwright-core@1.47.0-alpha-2024-08-19

Seems correct?

[mxschmitt]

Looks indeed good. How does your output/error look like when you run your tests?

For me its: expected to fail but passed after our fix.

[cooper667]

Looks indeed good. How does your output/error look like when you run your tests?

For me its: expected to fail but passed after our fix.

Yea, all good now, sorry