microsoft/playwright

[BUG] Non-spec files displayed in UI mode

scebotari66 opened this issue · 5 comments

scebotari66 commented

Hello, team!

We have noticed that if you have an error in the dependency of a spec, then in UI mode, the dependency file where the error occurred is displayed instead of the spec file. This seems like a bug.

Running npx playwright list-files lists the correct spec files.

Related to #24293

System info

  • Playwright Version: [v1.36.2]
  • Operating System: [macOS 13.4]
  • Browser: [All]

Source code

  • I provided exact source code that allows reproducing the issue locally.

Link to the GitHub repository with the repro

https://github.com/scebotari66/playwright-ui-mode-display-bug

Steps

  • Run npx playwright test --ui

Expected

a-file.spec.js and b-file.spec.js to be displayed in "Tests"

Actual

another-file.js and b-file.spec.js are displayed
image

pavelfeldman commented

What would be your expectations for this use case?

scebotari66 commented

For the a-file.spec.js spec file to be displayed in the tree instead of another-file.js. IMO is confusing to see non-spec files in there. And it also not clear what spec file actually imports the faulty dependency.

pavelfeldman commented

For the a-file.spec.js spec file to be displayed in the tree instead of another-file.js. IMO is confusing to see non-spec files in there. And it also not clear what spec file actually imports the faulty dependency.

In this case we won't be able to show the location of the error though. Not sure if that serves the user better, let me leave it open to feedback.

scebotari66 commented

Ideally, the location of the error would be displayed once you select the spec file from the tree in some sort of stack trace section.

pavelfeldman commented

Why was this issue closed?

Thank you for your contribution to our project. This issue has been closed due to its limited upvotes and recent activity, and insufficient feedback for us to effectively act upon. Our priority is to focus on bugs that reflect higher user engagement and have actionable feedback, to ensure our bug database stays manageable.

Should you feel this closure was in error, please create a new issue and reference this one. We're open to revisiting it given increased support or additional clarity. Your understanding and cooperation are greatly appreciated.