L’élément est là, et le clic ne fait rien

La capture montre le bouton. Set-of-Mark le numérote. Le clic annonce un succès, et rien ne bouge. Trois niveaux de recours, dans l’ordre où les essayer.

Le symptôme. L’élément est visible sur la capture. Set-of-Mark lui a donné un numéro. Vous cliquez, vous obtenez succes: true — et la page ne bouge pas.

Ou bien vous obtenez un délai dépassé sur un élément que vous voyez très bien sur la capture.

Pourquoi un élément visible peut refuser le clic

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 qu’aucun autre ne le recouvre. Cette vérification est une qualité : elle vous évite de cliquer sur la couche d’un indicateur de chargement en croyant atteindre le bouton derrière.

Elle se déclenche aussi sur des éléments qu’une personne peut cliquer. Un interrupteur habillé d’un style CSS maison, un bouton dans un <dialog> ouvert par showModal(), un élément sous une couche décorative qui ne reçoit pas les événements du pointeur — tous réels, tous interactifs, tous refusés.

Trois niveaux, dans cet ordre

1 — Le clic simple. Commencez toujours par là. S’il marche, rien d’autre ne compte.

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

2 — force: true. Passe outre la vérification d’interactivité de Playwright et clique quand même. C’est la bonne réponse pour un élément bien présent qui échoue à la vérification.

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

3 — repli_js: true. Un second niveau, pas un remplaçant du premier. Diwall réessaie avec un clic JavaScript sur l’élément lui-même — le même el.click() que vous écririez sinon à la main dans une action evaluer, intégré à cliquer.

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

Il ne s’exécute qu’après l’échec réel d’un clic natif. Poser l’option ne force pas le JavaScript à chaque clic.

Savoir quel niveau a fait le travail

La boussole vous le dit, et seulement quand le recours a vraiment eu lieu :

"boussole": {"repli_js_utilise": true}

Le champ apparaît quand le repli s’est exécuté, jamais du seul fait que l’option était posée. Vous apprenez ainsi si votre cible a réellement besoin du niveau 3 — bon à savoir avant de recopier l’option sur chaque action du scénario.

Une incompatibilité, et elle échoue bruyamment repli_js exécute du JavaScript, ce que –no-evaluer interdit pour toute l’exécution. Un scénario qui combine les deux est refusé à la validation (arguments_incompatibles, code 2) avant le démarrage du moindre navigateur — jamais une option ignorée en silence.

Le cas qui se ressemble et n’est pas le même

Si le clic échoue sur un élément situé dans une boîte de dialogue ouverte lors d’un appel précédent, aucun niveau de recours ne vous sauvera. La boîte de dialogue a disparu : reprendre une session recharge la page, et une boîte de dialogue showModal() ne survit pas à un rechargement.

C’est un autre problème, avec un autre remède. La session n’est pas conservée entre deux appels →

En bref

Essayez le clic simple, puis force: true, puis repli_js: true. Dans cet ordre.
repli_js ne se déclenche que sur un échec réel — ce n’est pas un clic JavaScript à la demande.
Regardez repli_js_utilise pour savoir ce que votre cible exige vraiment.
Un clic qui échoue sur un élément venu d’un appel précédent est un problème de session, pas de clic.