Le formulaire signale un succès et ne soumet jamais les données

Le symptôme. Vous remplissez un formulaire, cliquez sur “envoyer”, et vous obtenez succes: true — et le résultat reste inchangé. La consultation de la page par la suite affiche la même page, ou la page d’accueil, mais jamais la page de résultats que vous attendiez.

Deux causes distinctes produisent ce résultat identique. Distinguez-les avant de chercher une solution, sinon vous appliquerez la mauvaise.

Cause 1 : Le navigateur l’a bloqué, et il l’a signalé discrètement

Validation HTML5. Un champ marqué required est vide, ou un type="email" contient quelque chose qui ne l’est pas. Le navigateur refuse la soumission et affiche une petite bulle native — Veuillez remplir ce champ — ancrée au champ concerné.

Dinoer signale que le clic a été enregistré comme réussi, car c’était le cas : le clic s’est produit. Le navigateur a simplement refusé de prendre en compte cet événement.

Comment le reconnaître. Le attendre_navigation qui apparaît juste après le clic revient en environ 0 ms. Rien n’est affiché car rien n’a été envoyé. Lisez le a11y_tree résultant : le texte de la bulle s’y trouve, il est facile de ne pas le voir si vous ne vérifiez que le succes.

La correction. Remplissez le champ manquant. Si le champ doit rester vide intentionnellement, soumettez directement le formulaire et contournez la validation native :

{"type": "evaluer",
 "script": "document.querySelector('#my-form').submit()"}

Cause 2 : Un clic JavaScript n’est pas une soumission

Celle-ci est plus surprenante. Appeler .click() sur un bouton de soumission depuis JavaScript déclenche l’événement DOM click, mais ne garantit pas la soumission HTTP du formulaire parent. Les navigateurs traitent un clic synthétique différemment d’un clic utilisateur, surtout lorsque des gestionnaires de validation sont attachés.

Observé lors d’une mise à jour réelle du thème WordPress : le processus s’est terminé succes: true, la page résultante affichait la page d’accueil de WordPress, et aucun thème n’avait été mis à jour.

{"type": "evaluer",
 "script": "document.querySelector('input[name=upgrade]').click()"}

La solution : toujours sous cette forme.

{"type": "evaluer",
 "script": "document.querySelector('input[value=\"theme-slug\"]').closest('form').submit()"}

.closest('form').submit() appelle directement la méthode de soumission native du navigateur. .click() sur un bouton de soumission demande poliment ; .submit() fait le travail.

La règle à conserver

Pour soumettre un formulaire depuis <code>evaluer</code>, utilisez toujours <code>.closest('form').submit()</code> — n’utilisez jamais <code>.click()</code> sur le bouton de soumission.

Et si vous n’êtes pas du tout dans evaluer, préférez un véritable cliquer sur le bouton : Le clic natif de Playwright se comporte comme celui d’un utilisateur, ce qui est exactement ce qu’un clic synthétique ne fait pas.

Avant de conclure

Une soumission qui semble avoir échoué peut en réalité avoir réussi. Une requête POST lente — un clonage, une importation, ou toute opération prenant des dizaines de secondes — peut atteindre le délai d’attente alors que le serveur continue et termine le travail. TimeoutError lors d’un clic signifie que Playwright a cessé d’attendre, et non qu’il ne s’est rien passé.

Vérifiez la cible avant de réessayer, ou vous exécuterez l’opération deux fois. L’opération qui prend du temps →

En bref

• Deux causes, un symptôme : la validation native l’a bloqué, ou un script JS .click() n’a jamais été exécuté.
• ~0 ms sur attendre_navigation après le clic = rien n’a été envoyé.
• Depuis evaluer: .closest('form').submit(), toujours.
• Un délai d’attente n’est pas une erreur — vérifiez avant de réessayer.