L'élément est présent, mais le clic ne fait rien

Le sélecteur correspond au bouton. Le clic signale un succès, et rien ne se déplace. Deux niveaux d'escalade, dans l'ordre à essayer.

Le symptôme. Le sélecteur correspond à un élément réel et visible. Vous cliquez dessus, vous obtenez succes: true — et la page ne se charge pas. Ou vous rencontrez un délai d’attente sur un élément dont l’existence peut être confirmée via --a11y.

Pourquoi un élément réel peut ne pas être cliquable

Playwright refuse de cliquer sur ce qu’une personne ne pourrait pas cliquer. Avant d’agir, il vérifie que l’élément est visible, stable et n’est pas masqué par autre chose. Cette vérification est une fonctionnalité : elle vous empêche de cliquer sur un indicateur de chargement (spinner) et de croire que vous avez cliqué sur le bouton qui se trouve derrière.

Il se déclenche également sur les éléments sur lesquels une personne peut cliquer. Un bouton avec un style personnalisé et une feuille de style CSS, un bouton à l’intérieur d’un <dialog> ouvert par showModal(), un élément sous une couche décorative sans événements de pointeur : tout est réel, tout est interactif, mais tout est rejeté.

Deux niveaux, dans cet ordre :

1 — Simple clic. Commencez toujours par là. Si cela fonctionne, le reste n’a pas d’importance.

{"type": "cliquer", "selecteur": "#confirm"}

2 — force: true. Ignore la vérification d’interactivité de Playwright et clique de toute façon. C’est la bonne réponse pour un élément qui est réellement présent mais échoue à la vérification.

{"type": "cliquer", "selecteur": "#confirm", "force": true}

3 — repli_js: true. Un deuxième niveau, qui ne remplace pas le premier. Dinoer essaie à nouveau en utilisant un clic JavaScript sur l’élément lui-même : la même el.click() que vous écririez normalement manuellement dans une action evaluer, intégrée dans cliquer.

{"type": "cliquer", "selecteur": "#dialog-confirm button[type=submit]",
 "force": true, "repli_js": true}

Cela ne fonctionne que après qu’un clic natif ait réellement échoué. Définir ce paramètre n’active pas JavaScript pour chaque clic.

Comment savoir quel niveau a effectué le travail ?

La boussole vous l’indique, et seulement lorsque l’escalade s’est réellement produite :

"boussole": {"repli_js_utilise": true}

Le champ apparaît lorsque le mécanisme de secours est activé, et non simplement parce que l’indicateur a été défini. Vous pouvez ainsi déterminer si votre cible a réellement besoin du niveau 3, ce qui vaut la peine de savoir avant de copier cet indicateur sur chaque action dans le scénario.

Une incompatibilité, et cela échoue bruyamment. repli_js exécute JavaScript, ce que –no-evaluer interdit pour toute la durée de l’exécution. Un scénario combinant les deux est rejeté lors de la validation (sortie 2) avant même que n’importe quel navigateur ne démarre — jamais un simple refus silencieux.

Le cas qui semble identique mais ne l’est pas

Si le clic échoue sur un élément à l’intérieur d’une boîte de dialogue que vous avez ouverte lors d’un appel précédent, aucun niveau d’escalade ne pourra vous aider. La boîte de dialogue a disparu : la reprise d’une session recharge la page, et une boîte de dialogue de type showModal() ne survit pas à un rechargement.

C’est un problème différent avec une solution différente. La session ne persiste pas entre deux appels →

En bref

Essayez d’abord sans formatage, puis force: true, puis repli_js: true. Dans cet ordre.
repli_js nécessite une véritable erreur pour être déclenché ; ce n’est pas un simple clic JavaScript à la demande.
Vérifiez repli_js_utilise pour savoir ce que votre cible exige réellement.
Un clic qui échoue sur un élément provenant d’un appel précédent est un problème de session, et non un problème de clic.