Gathering trace data from iframe targets

[rggammon]

FAQ

• Yes, my issue is not about variability or throttling.
• Yes, my issue is not about a specific accessibility audit (file with axe-core instead).

URL

puppeteer/puppeteer#8991

What happened?

I am working with a site that uses cross-domain iframes, and notice that when I load a trace gathered by lighthouse into the devtools timeline/profiler viewer, I don't see data for the iframe. eg: js sample data, w/ #15542

What did you expect?

I'd like to see trace data for cross-domain iframes

What have you tried?

There is some discussion of this in puppeteer/puppeteer#8991

My hypothesis based on puppeteer/puppeteer#8991 would be that tracing needs to be enabled on these iframe targets as they are attached, similar to how Network.enable is being called per-session on attach -

lighthouse/core/gather/driver/target-manager.js

Line 162 in 912495d

await newSession.sendCommand('Network.enable');

And then, I think with flat protocol mode, traces for all the targets would have sessionId's and it is possible to merge all the trace events in one json file and devtools can load this combined file and show all frames in timeline/profile view.

How were you running Lighthouse?

node

Lighthouse Version

11.5.0

Chrome Version

No response

Node Version

No response

OS

Linux

Relevant log output

No response

[adamraine]

I am seeing information for cross-origin iframes in traces collected by Lighthouse. For example:

https://trace.cafe/t/YgqEQVRVS9

This page contains several iframes and the data for each frame is present in the trace. I got the trace by running the following command:

lighthouse https://www.paulirish.com/2012/why-moving-elements-with-translate-is-better-than-posabs-topleft/ -G

Then I loaded latest-run/defaultPass.trace.json into a trace viewer (in this case trace.cafe but the DevTools performance panel is the same).

Maybe I'm misunderstanding something. What steps can I take to reproduce what you are seeing?

[rggammon]

Thank you for the cli pointer - indeed it is working for me there. Here is a trace of paulirish.com with my setup where I don't see the iframes - https://trace.cafe/t/ZJoILNJNJX

Given that it is working with the cli, I should be able to compare my setup to this, and can report back with what the issue was.

[adamraine]

@rggammon are you launching Chrome in old headless mode? I believe this was the default when using Puppeteer before Puppeteer v22.x.

In old headless mode, OOPIFs are disabled and so iframe thread activity will appear on the main thread.

If this is the case, using the new headless mode should be enough to fix the issue.

[rggammon]

@adamraine I am actually launching chrome via playwright launchPersistentContext with headless: true - which is likely the issue. Thank you for the pointer! Will figure out how to get launchPersistentContext using new headless mode, and can post that here & resolve this

[rggammon]

My issue wasn't with lighthouse but with how it is getting run -

• Playwright has an environment variable, PLAYWRIGHT_CHROMIUM_USE_HEADLESS_NEW, that is needed to get --headless=new https://github.com/microsoft/playwright/blob/291567b922ff9afe8357103e005292a8464bbc85/packages/playwright-core/src/server/chromium/chromium.ts#L316
• Playwright config for our site is setting things like --disable-features=IsolateOrigins --disable-site-isolation-trials
• Setting DEBUG_FILE=... and DEBUG="pw:*" includes how playwright is running chromium, and for lighthouse cli, adding --verbose shows how lighthouse is running chrome, and the differences here are the source of my issue.

Closing the bug, thank you again for the pointers!