[Feature]: Show step call location in test output when step fails

[ScarletMcLearn]

🚀 Feature Request

Problem Currently, when a test step fails (using test.step()), the Playwright report only shows the location where the step is defined, not where it was called from.

This becomes problematic in real-world frameworks where shared utility steps are reused across multiple test files. When a failure happens, the report points to the utility file, making it hard to determine which test actually called the step.

Example – Current Behavior

// utils/my_steps.ts
export async function fillLoginForm(page: Page) {
  await test.step("Fill login form", async () => {
    await page.fill('#username', 'admin');
    await page.fill('#password', 'password');
  });
}

// tests/test_a.spec.ts
test('Login from A', async ({ page }) => {
  await fillLoginForm(page); // if it fails, only shows fillLoginForm() from utils
});

On failure, the Playwright report shows:

Step: Fill login form
File: utils/my_steps.ts:2
But it doesn’t show that the call originated in tests/test_a.spec.ts:3.

Example

Expected Behavior When a step fails, Playwright should include both:

1. The location of the test.step() definition (for context)
2. The call location (the line in the test file where the step was invoked)

This would make it significantly easier to debug step failures and choose alternate steps where needed.

Ideal Output Format (Example)

Step: Fill login form
Called from: tests/test_a.spec.ts:3
Defined in: utils/my_steps.ts:2

Motivation

Why It Matters

1. Helps debugging large test suites with shared reusable steps
2. Enables quicker triage when the same step is reused with different preconditions
3. Avoids blindly assuming all failures are from the same root cause

[Skn0tt]

Have you tried out the box parameter in test.step? That should solve your problem: https://playwright.dev/docs/api/class-test#test-step-option-box

[ScarletMcLearn]

Thank you @Skn0tt for the suggestion.

I have tried it.

As you can see my step is boxed, but when ran in hooks they fail to point to appropriate source.

[Skn0tt]

It works fine when I test it on my end. Could you provide me with a reproduction case I can use to look at this locally? There's a chance this is related to something like sourcemaps that's specific in your project.

[ScarletMcLearn]

Sure. I'll share soon!

[ScarletMcLearn]

Hi @Skn0tt . I have been trying to reproduce a minimal repository to reproduce the issue, but unfortunately its working fine in simple use cases. Anything else I can give to investigate further?

[Skn0tt]

Are you able to share the repository where you're experiencing this, possibly in private via email?

[ScarletMcLearn]

Of course. I can do that. Thank you for the support. I have sent the relevant files to your mail. @Skn0tt

[Skn0tt]

We discussed this via email, but there was no repro. @ScarletMcLearn please open another issue with a reproduction case once you have it.