fix(frames): treat elements inside hidden iframes as hidden

[Dmitry Gozman (dgozman)]

Summary

• Frame element visibility is determined during selector resolution and passed to the injected script, so elements inside a visibility: hidden iframe are considered hidden, including cross-origin frames.
• Actions that wait for visibility bail out early and retry while the frame is hidden.
• frameVisible is a required argument for elementState() visibility checks.

Fixes #42719

[github-actions]

Test results for "tests 1"

6 flaky

⚠️ [installation tests] › playwright-cli.spec.ts:21 › cli should work `@package-installations-ubuntu-latest`
⚠️ [chromium-library] › library/video.spec.ts:521 › screencast › should capture static page in persistent context Radoslav Kirilov (@smoke) `@realtime-time-library-chromium-linux`
⚠️ [chromium-library] › library/popup.spec.ts:260 › should not throw when click closes popup `@chromium-ubuntu-22.04-node24`
⚠️ [firefox-library] › library/browsercontext-cookies-third-party.spec.ts:257 › third party 'Partitioned;' cookies `@firefox-ubuntu-22.04-node20`
⚠️ [firefox-library] › library/browsercontext-cookies-third-party.spec.ts:470 › top level 'Partitioned;' cookie and same origin iframe `@firefox-ubuntu-22.04-node20`
⚠️ [webkit-page] › page/page-leaks.spec.ts:136 › expect should not leak `@webkit-ubuntu-22.04-node20`

52122 passed, 1241 skipped

---

Merge workflow run.

[github-actions]

Test results for "MCP"

1 failed
❌ [firefox] › mcp/cli-devtools.spec.ts:140 › request* and response* commands support --filename @mcp-windows-latest-firefox

8704 passed, 1474 skipped

---

Merge workflow run.

[github-actions]

🟢 CI is clear — the one failure is a known flake

Hi, I'm the Playwright bot and I triaged the failing CI run.

The only real failure is [firefox] › mcp/cli-devtools.spec.ts:140 › request* and response* commands support --filename on mcp-windows-latest-firefox. It has failed with the identical error on four other unrelated PRs, so it isn't yours.

Details

This PR touches iframe visibility resolution (injectedScript.ts, dom.ts, frameSelectors.ts, frames.ts, screenshotter.ts). Nothing in that path is exercised by the MCP devtools CLI request/response commands, and the assertion that fails is about a saved --filename artifact, not element state.

Pre-existing flake / infra

• [firefox] › mcp/cli-devtools.spec.ts:140 › request* and response* commands support --filename (mcp-windows-latest-firefox) — in the aggregated CI results this test has run 702 times on that bot and failed 5 times (0.7%), always with the same expect(received).not.toBeNull() / Received: null. The other four failures are on PRs feat(locator): introduce locator.visible() #42479 (sha 5cc92193), fix(test): support multiple contexts with --debug=cli #42503 (7df53e86), fix(chromium): report 204 subresource responses as finished #42834 (30421c61) and feat(webkit): roll to r2366 #42879 (7788c78e). It has never failed on any of the other 12 MCP bots (~8600 runs), so it's a Windows+Firefox timing flake in the devtools CLI, not a regression here.

The six flaky entries in the "tests 1" report (installation CLI, video.spec.ts:521, popup.spec.ts:260, two third-party cookie tests, page-leaks.spec.ts:136) all passed on retry and are spread across browsers and unrelated areas — nothing to triage there.

I'd just re-run the MCP job.

_{Triaged by the Playwright bot - agent run}