Das Element befindet sich innerhalb eines Iframes und ein einfacher Selektor kann es nicht erreichen
Ein Zahlungsmodul, ein eingebetteter Editor, ein Formular von Drittanbietern. Der Rahmenrand ist eine Sicherheitsgrenze des Browsers und keine Fehlfunktion – und zwei eingeschränkte Aktionen überschreiten ihn korrekt.
Das Symptom. Die Seite wird normal angezeigt – ein Formular ist vorhanden, ein Zahlungsmodul, ein eingebetteter Editor, ein Buchungsmodul eines Drittanbieters. Ein einfacher cliquer oder remplir mit einem CSS-Selektor findet nichts darin, und der Barrierefreiheitsbaum endet ebenfalls am Rand des Frames.
Warum es dort aufhört
Ein <iframe> ist ein separates Dokument. Wenn es von einer anderen Quelle stammt, verhindert der Browser, dass die Seite – und alle darin laufenden Skripte – darauf zugreifen können. Das ist eine strikte Sicherheitsgrenze, und das ist gut: Sie verhindert, dass jede Website den Inhalt eines Zahlungsfensters lesen kann, das sie einbettet.
Es gibt keine Option, um dies zu aktivieren, und das sollte auch so bleiben: Das Aktivieren einer solchen Funktion wäre eine Sicherheitslücke im Browser, kein fehlendes Feature.
Zwei vordefinierte Aktionen überlappen es korrekt
Der Playwright greift über das Debugging-Protokoll in Frames ein, anstatt Skripte einzufügen, was legitim ist, wo eine solche Einfügung nicht möglich wäre. Dinoer stellt dies als zwei Aktionen bereit:
{"type": "cliquer_iframe", "iframe_selecteur": "iframe#payment",
"selecteur": "button.confirm"}
{"type": "remplir_iframe", "iframe_selecteur": "iframe#payment",
"selecteur": "input[name=cvv]",
"valeur": "depuis_secrets", "secret_cle": "cvv"}
remplir_iframe unterstützt depuis_secrets und depuis_secrets_totp genau
wie remplir – ein Anmeldeinformationsobjekt innerhalb eines Frames wird weiterhin im Browserprozess verarbeitet,
und niemals in der Szenarienbeschreibung festgehalten.
Die Funktion force: true ist auch in cliquer_iframe verfügbar: Die Interaktionsregeln von Playwright gelten innerhalb des Frames genauso wie außerhalb.
Ein Iframe innerhalb eines Iframes
Ein Iframe innerhalb eines Iframes.
iframe_selecteur zielt auf einen obersten Frame ab. Verschachtelte Frames benötigen eine Abfolge, die jeden Level durchläuft, und zwar in folgender Reihenfolge:
{"type": "cliquer_iframe",
"iframe_chemin": ["iframe#wrapper", "iframe#payment"],
"selecteur": "button.confirm"}
Ein sortiertes Array, wobei pro Verschachtelungsebene ein CSS-Selektor angegeben wird. Die beiden Formen sind gegenseitig ausschließend – verwenden Sie eine oder die andere, aber nicht beide.
Die Grenze, klar und deutlich formuliert
Es gibt keine Zugänglichkeitsbaumstruktur innerhalb des Frames. Sie benötigen den internen CSS-Selektor selbst.
Woher man es bekommt: Wenn das iframe die gleiche Herkunft hat, kann ein evaluer darauf zugreifen –
document.querySelector('iframe').contentDocument. Wenn es eine andere Herkunft hat,
können Sie es nicht von der Seite erhalten: Lesen Sie die eigene Dokumentation des Drittanbieters oder öffnen Sie die URL des Frames direkt in einem Browser und untersuchen Sie ihn dort.
Dies ist eine erste Freigabe, noch keine vollständige Wahrnehmung von iframes. Das zu sagen ist hilfreicher, als wenn Sie es selbst herausfinden müssten, während ein Formular nicht richtig funktioniert.
Kurz gesagt
- Cross-Origin-Iframes stellen eine harte Browsergrenze dar – kein Flag entfernt diese, absichtlich.
cliquer_iframe/remplir_iframemitiframe_selecteurfür eine Ebene.iframe_chemin– ein geordnetes Array – für verschachtelte Frames.- Die Authentifizierung, einschließlich TOTP, funktioniert innerhalb von Frames genau wie außerhalb.
- Sie geben den inneren Selektor an; Dinoer stellt die Verbindung bereit.