[Bug]: getAttribute steps don't appear in the trace anymore since 1.53

[Germandrummer92]

Version

1.53.2

Steps to reproduce

1. run test (but anything with getAttribute will work)

import {expect, test} from "@playwright/test";

test.describe("try mui X", () => {
    test.only("should be able to get attribute", async ({ page }) => {
        await page.goto("https://mui.com/x/react-date-pickers/");

        let something = page.getByLabel("Outbound").nth(1);
        const value = await something.getAttribute("class");

        expect(value).not.toBeNull();
    });
});

with trace enabled
2. open trace

Expected behavior

Trace has "getAttribute" step visible.

in 1.52:

trace:

trace.zip

Actual behavior

No "getAttribute" step is visible:

in 1.53.2:

trace:

trace.zip

Additional context

No response

Environment

System:
    OS: macOS 15.5
    CPU: (10) arm64 Apple M1 Pro
    Memory: 118.30 MB / 32.00 GB
  Binaries:
    Node: 22.11.0 - ~/.nvm/versions/node/v22.11.0/bin/node
    npm: 10.9.0 - ~/.nvm/versions/node/v22.11.0/bin/npm
    pnpm: 9.15.9 - ~/.nvm/versions/node/v22.11.0/bin/pnpm
  Languages:
    Bash: 3.2.57 - /bin/bash
  npmPackages:
    @playwright/test: 1.53.2 => 1.53.2

[dgozman]

@Germandrummer92 Indeed, there was a change in 1.53 that hides getAttribute() and similar calls from the trace. Could you please explain the usecase where you'd like to see those in the trace? We would like to understand the scenario to better help you. The more details you provide the better!

[Germandrummer92]

@dgozman 2 reasons :)

a) I think it's quite confusing if you have an error in the getAttributeCall, e.g. for this code:

import {expect, test} from "@playwright/test";

test.describe("try mui X", () => {
    test.only("should be able to get attribute", async ({ page }) => {
        await page.goto("https://mui.com/x/react-date-pickers/");

        const value = await page.getByText("broken").getAttribute("doesntexist");

    });
});

that produces this:
trace.zip

in the trace you do NOT see a red step even though the test of course correctly fails. (and yeah the error is of course available, but I think it's a bit confusing that there is no red step on the left side).

and b) (probably less relevant for you), but we are building an abstraction over playwright at octomind.dev and we rely on parsing the trace to be able to visualize a test execution well. Now with the step not being present anymore that got a little more difficult for us in this case.

[pavelfeldman]

How comfortable are you folks at playwright source base? Will we regret if we ask you to change the implementation in a way that stores all the instrumentation signals in the trace and allows filtering them in the UI with the default filter that hides idempotent / getter operations?

[Germandrummer92]

Hey @pavelfeldman @dgozman,

I think we feel reasonably confident in tackling this, but always looking to learn. The plan would be:

• Add the internal boolean flag to ActionTraceEvents - 2 options i guess:
  • either we add the internal to the v8 ActionTraceEvent types and just emit internal:false for all existing events in the traceModernizer
  • OR do an explicit v9, not sure what is the better approach
  • We're happy with implementing either one - please advise.
• in recorder/tracing.ts: write events even if they are marked as internal: true, by passing through the internal value
• Filter in trace-viewer-ui, in the WorkbenchLoader -> filter out the internal context entries before the creation of the trace model in the workbenchLoader/liveWorkbenchLoader.
• I am not sure if the codegen window/code also relies on this and would need adjustment as well? i think not but please correct me if I'm wrong.
• (optional) allow showing the internal trace viewer events in the trace viewer, I'm not sure if there would be any problems with displaying some of them?

We likely won't get to it right away, but in the next 2-3 weeks if that would fit your timeline, then we would be very willing to tackle it.