[Bug]: ariaSnapshot({ mode: 'ai' }) omits iframe contents when the <iframe> element has fallback text
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 30/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Ferma
- Stack tecnologico
- playwright, typescript
- Ambito
- backend-api-design, testing-qa
Direzione di ricerca
Start with mergeIframeChildren and the YAML renderer behavior described in the issue. Compare how the iframe node's text and captured child snapshot are handled, and check the existing tests for ariaSnapshot({ mode: 'ai' }) and iframe contents. Done means the fallback page snapshot includes the child frame's heading, paragraph, textbox, and button, while unavailable frames retain their fallback text.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Version
playwright-core 1.64.1 (also the 1.64.0-alpha bundled with @playwright/mcp 0.0.83). Chromium headless shell 1248, Windows 11.
Bug
page.ariaSnapshot({ mode: 'ai' }) (the snapshot @playwright/mcp returns) omits the whole contents of a same-origin iframe whenever the <iframe> element has text between its tags (fallback content). The child frame is captured, but the output only shows the fallback text.
Repro
child.html
<!doctype html><title>child</title><h1>Child heading</h1><p>Intro text in frame</p>
<form><label>One <input name=one></label><button type=button>Eggs, Sausages</button></form>
plain.html
<!doctype html><title>plain</title><h1>Outer</h1><iframe src="child.html" title="plain-frame"></iframe>
fallback.html (same, but with text inside the iframe element)
<!doctype html><title>fallback</title><h1>Outer</h1><iframe src="child.html" title="fallback-frame">Your browser does not support frames</iframe>
const { chromium } = require('playwright-core');
(async () => {
const b = await chromium.launch(); const p = await b.newPage();
for (const f of ['plain', 'fallback']) {
await p.goto(require('url').pathToFileURL(require('path').join(__dirname, f + '.html')).href);
console.log('== ' + f + ' ==\n' + await p.ariaSnapshot({ mode: 'ai' }));
}
await b.close();
})();
Actual
== plain ==
- generic [active] [ref=e1]:
- heading "Outer" [level=1] [ref=e2]
- iframe [ref=e3]:
- generic [ref=f1e1]:
- heading "Child heading" [level=1] [ref=f1e2]
- paragraph [ref=f1e3]: Intro text in frame
- generic [ref=f1e4]:
- generic [ref=f1e5]:
- text: One
- textbox "One" [ref=f1e6]
- button "Eggs, Sausages" [ref=f1e7]
== fallback ==
- generic [active] [ref=f2e1]:
- heading "Outer" [level=1] [ref=f2e2]
- iframe [ref=f2e3]: Your browser does not support frames
Expected
The fallback snapshot lists the child frame's heading, paragraph, textbox and button like plain does. Fallback text is only used by browsers that can't render frames, so it should not replace content that was successfully captured.
Likely cause
In the iframe merge step (mergeIframeChildren in the bundled core) the captured child snapshot is assigned with node.children = childSnapshot but the iframe node's existing text (the fallback text) is left in place. The YAML renderer prefers node.text over node.children (if (node.text !== undefined) visitText(...) else for (const child of node.children ...)), so the children are never printed. Clearing node.text when childSnapshot?.length is truthy (and keeping it when the frame is genuinely unavailable) should fix it.
Impact
Pages that put fallback text inside <iframe> (common on older/legacy pages and some test sites) look like they have an empty frame to agents using @playwright/mcp: no content, no refs for the controls inside, and no hint that the frame loaded. Seen in a browser-agent benchmark where agents given the tree snapshot could not read or interact with the frame form.
- Lingua principale
- TypeScript
- Stelle
- 98.5k
- Fork
- 6.7k
- Merge medio
- 15h 43m
- PR unite (30g)
- 279
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di microsoft/playwright
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 70/100
microsoft/playwright#43640 ·
I maintainer di solito rispondono entro 1 giorno
-
[Bug]: `playwright install` hangs silently for ~8 minutes when PLAYWRIGHT_BROWSERS_PATH is not writableForse già presa @dcrousso l’ha presa 2 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
microsoft/playwright#43606 ·
I maintainer di solito rispondono entro 1 giorno
-
[Feature]: Set `this.name` in `TargetClosedError` constructorForse di nuovo libera @LeonxLJX l’ha presa 52 giorni fa e non c’è nessuna pull request aperta. ApertaP3-collecting-feedback
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 86/100
microsoft/playwright#42522 · 7 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
[Bug]: connectOverCDP kills the process with an uncaught assertion when an attached target has no browserContextIdForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 68/100
microsoft/playwright#43638 ·
I maintainer di solito rispondono entro 1 giorno
-
needs-triage-win
Difficoltà 3/5 1-2 giorni Idoneità per principianti 58/100
microsoft/playwright#43632 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di microsoft/playwright
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
grafana/profiles-drilldown#1212 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
grafana/traces-drilldown#980 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
openremote/openremote#3487 · 1 commento ·
-
triage:needs-human
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
garrytan/gbrain#7635 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
coollabsio/jean#867 ·
I maintainer di solito rispondono entro 1 giorno