[Bug]: Since 1.58, Request can't be checked until the whole execution is done

[samixchoumi]

Version

1.58.0

Steps to reproduce

Seem to happen on every API/E2E projects (I use chrome and chromium).
When I execute a test, I now need to wait for the full execution if I want to be able to check some issue of a previous failing test.

Command to execute to launch UI mode : npx playwright test --ui
When it's opened, execute multiple test (like 10 tests in a row using 1 worker to better understand the issue), when the first one is done, try access request from this finished test, impossible, you're always kicked out.
Same if you want to follow the test execution of the current test. It's very laggy.

Reverting to 1.57.1 fix this wrong behavior, a bit sad as the new UI from 1.58 is really better.

Expected behavior

No laggy behavior when looking at a test execution and allow to check request without removing the focus as it was done on previous version.

Actual behavior

Too much lag/unfocus/weird behavior happening.

Additional context

No response

Environment

System:
    OS: macOS 26.2
    CPU: (8) arm64 Apple M1 Pro
    Memory: 80.19 MB / 16.00 GB
  Binaries:
    Node: 22.14.0 - /opt/homebrew/bin/node
    Yarn: 1.22.19 - /opt/homebrew/bin/yarn
    npm: 11.7.0 - /opt/homebrew/bin/npm
    pnpm: 8.10.3 - /usr/local/bin/pnpm
  IDEs:
    VSCode: 1.106.3 - /opt/homebrew/bin/code
  Languages:
    Bash: 3.2.57 - /bin/bash
  npmPackages:
    @playwright/test: ^1.58.0 => 1.58.0 
    playwright-bdd: ^8.4.2 => 8.4.2 
    playwright-slack-report: ^1.1.100 => 1.1.100

[veykos]

I'm observing the same issues, running tests in the UI mode with 6 workers in parallel almost crashes the UI. It's especially bad when trying to hover over a test name on the sidebar, even the loading animations lag.
Other than that, even if tests manage to pass without the UI crashing, checking anything - moving through timeline, hovering over the steps of the test to see the snapshots feels way laggier than in 1.57 to the point of being almost unusable.

This is on a MacBook M2 Max - 64 GB or RAM,
OS Version:

ProductName:            macOS
ProductVersion:         15.7.2
BuildVersion:           24G325

EDIT: With some test suites extended on the left side panel, showing the tests inside of them, even hovering over the test names quickly up and down causes CPU spikes up to 600%!!! of Google Chrome for Testing Helper (GPU) in Activity Monitor

[samixchoumi]

True, I didn’t tested with more than 3 workers with UI mode but increasing it to 5/6 on E2E test make it crash after some delay of test executions.

[pavelfeldman]

@cpAdm I can repro the network selection issue. Do you want to take a look at it?

[pavelfeldman]

Thanks for the report! I'm narrowing the title to what I can repro. I can't repro "very unstable" and "lag if following the execution". Please file separate issues for them with something I can repro!

[samixchoumi]

@pavelfeldman Do you have a template project with multiple tests that I could execute locally ?
As I can’t share my work project, I may try on some sample project if you have one available of course

EDIT : I just tested with https://github.com/microsoft/playwright-examples#, updating the playwright version to 1.58.0 and it's very complicated to use the UI mode. Especially the timeline that seem now useless until the full execution is done.
I will link a video in the next comment.
EDIT 2 : It seems that I can't upload the video...

[samixchoumi]

Here is the video using 1.58.0 version. Take a look at my mouse moving normally while the UI don't work at all or is very very slow compared to 1.57 usage.
Playwright-slow-2026-01-30 à 16.54.04.zip
You can see that when the execution is done, then it works properly as before.
I hope it helps to understand what I explained on my first comment. (and maybe put back my old title)

[pavelfeldman]

@samixchoumi i can see the video, it looks really bad. Let's file a separate issue for it though (I claimed this one to network).
for the video issue, can't repro it, using similar M1 to repro. Don't reply here please, file the issue!

[cpAdm]

@cpAdm I can repro the network selection issue. Do you want to take a look at it?

@pavelfeldman Seems to be regression introduced by #38691.

Struggling to get it to work properly. I believe the issue is that networkModel.resource is re-created, causing the === comparison to fail. Ideally the HAREntry has an unique id property that we could use, making comparing entries much easier.