L'élément se trouve à l'intérieur d'une iframe et un sélecteur simple ne peut pas l'atteindre

Le symptôme. La page s’affiche normalement : un formulaire est présent, ainsi qu’un widget de paiement, un éditeur intégré et un module de réservation tiers. Un simple cliquer ou remplir avec un sélecteur CSS ne trouve rien à l’intérieur, et l’arborescence d’accessibilité s’arrête également au bord du cadre.

Pourquoi cela s’arrête là

Un iframe est un document distinct. Lorsqu’il provient d’une autre origine, le navigateur empêche la page — et tout script qui s’exécute dans celle-ci — d’accéder à son contenu. Il s’agit d’une limite de sécurité stricte, et c’est une bonne chose : elle empêche tout site web de lire le contenu d’un cadre de paiement qu’il intègre.

Aucun indicateur ne permet d’activer cette fonctionnalité, et ce n’est pas souhaitable : activer un tel indicateur constituerait une vulnérabilité du navigateur, et non un manque de fonctionnalité.

Deux actions avec des portées différentes le traversent correctement

Playwright accède aux éléments à l’intérieur des frames via le protocole de débogage, plutôt que par l’injection de scripts, ce qui est une approche valide là où l’injection ne serait pas possible. Dinoer expose cette fonctionnalité sous forme de deux actions :

{"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 prend en charge depuis_secrets et depuis_secrets_totp exactement comme remplir : une information d’authentification à l’intérieur d’un cadre est toujours traitée par le processus du navigateur, et n’est jamais écrite dans le scénario.

force: true est également disponible sur cliquer_iframe : les règles d’interaction de Playwright s’appliquent à l’intérieur du cadre comme elles le font à l’extérieur.

Un iframe à l’intérieur d’un autre iframe

iframe_selecteur cible un seul cadre de niveau supérieur. Les cadres imbriqués nécessitent une descente à travers chaque niveau, dans l’ordre suivant :

{"type": "cliquer_iframe",
 "iframe_chemin": ["iframe#wrapper", "iframe#payment"],
 "selecteur": "button.confirm"}

Un tableau ordonné, avec un sélecteur CSS par niveau d’imbrication. Les deux formes sont mutuellement exclusives : utilisez l’une ou l’autre, mais pas les deux.

La limite, exprimée simplement

Il n’y a pas de structure d’arbre d’accessibilité à l’intérieur du cadre. Vous devez fournir vous-même le sélecteur CSS interne.

Où le trouver : si l’iframe est du même domaine, un evaluer peut y accéder — document.querySelector('iframe').contentDocument. Si elle provient d’un autre domaine, vous ne pourrez pas y accéder depuis la page : consultez la documentation propre du tiers concerné, ou ouvrez directement l’URL de l’iframe dans un navigateur et examinez-la.

Ceci est un premier déverrouillage, et non une fonctionnalité complète de reconnaissance des iframes. Le signaler est plus utile que de vous laisser le découvrir par vous-même en essayant de remplir un formulaire qui ne fonctionnera pas.

En bref

• Les iframes inter-domain sont une limite fondamentale du navigateur ; aucun paramètre ne la contourne, intentionnellement.
• cliquer_iframe / remplir_iframe avec iframe_selecteur pour un niveau.
• iframe_chemin — un tableau ordonné — pour les iframes imbriquées.
• La résolution des informations d’identification, y compris TOTP, fonctionne à l’intérieur des iframes exactement comme à l’extérieur.
• Vous fournissez le sélecteur interne ; Dinoer fournit la connexion.