Insertion de formulaire dans l'editeur et champ obligatoire en HTML5 #3664

Open
opened 6 years ago by miros · 18 comments
miros commented 6 years ago

Lorsqu'on insert un formulaire dans l'editeur via <formulaire|truc> et que ce formulaire contient des champs obligatoires.

Si on fait une prévisualisation, il devient impossible de sauvegarder l'article car les champs sont obligatoires.

Lorsqu'on insert un formulaire dans l'editeur via <formulaire|truc> et que ce formulaire contient des champs obligatoires. Si on fait une prévisualisation, il devient impossible de sauvegarder l'article car les champs sont obligatoires.
b_b commented 5 years ago
Owner

Je ne reproduis pas en SPIP 3.2.0-dev SVN [23116], tu peux me confirmer/infirmer que le bug est toujours présent en 3.1 ?
Statut changé à En cours

Je ne reproduis pas en SPIP 3.2.0-dev SVN [23116], tu peux me confirmer/infirmer que le bug est toujours présent en 3.1 ? **Statut changé à En cours**
b_b commented 5 years ago
Owner
There is no content yet.
b_b commented 5 years ago
Owner

Il semblerait que ça se confirme, cf le mail de jean marie sur spip-zone : https://www.mail-archive.com/spip-zone`rezo.net/msg43765.html

Il semblerait que ça se confirme, cf le mail de jean marie sur spip-zone : https://www.mail-archive.com/spip-zone`rezo.net/msg43765.html
Owner

une piste : utiliser l'attribut novalidate sur les form insérés dans le contenu éditable.

https://www.w3.org/TR/html5/forms.html#attr-fs-novalidate

une piste : utiliser l'attribut novalidate sur les form insérés dans le contenu éditable. https://www.w3.org/TR/html5/forms.html#attr-fs-novalidate
b_b commented 4 years ago
Owner

Donc, quand HTML5 est actif , il faudrait tenter d'ajouter en js un attribut novalidate aux formulaires présents dans la prévisu afin de voir si ça permet de contourner le bug.

https://developer.mozilla.org/fr/docs/Web/HTML/Element/Form#attr-novalidate

Donc, quand HTML5 est actif , il faudrait tenter d'ajouter en js un attribut `novalidate` aux formulaires présents dans la prévisu afin de voir si ça permet de contourner le bug. https://developer.mozilla.org/fr/docs/Web/HTML/Element/Form#attr-novalidate
Owner

corrigé par f848927c9d
Version cible mise à 4.0
Statut changé à Fermé

corrigé par https://git.spip.net/spip/porte_plume/commit/f848927c9de52eeca90898838361918d1050001e **Version cible mise à 4.0** **Statut changé à Fermé**
Owner

\o/

\o/

Commentaire reporté du ticket doublon fermé #4952

Lors de la modification d'un article qui contient un formulaire avec un champ obligatoire il est impossible d'enregistrer les modifications si elles ont été modifiées en fullscreen.
Le bouton enregistrer est inactif. Workaround : copier les modifs, faire retour à l'article puis modifier dans la page d'édition "normale"
(problème rencontré avec un formulaire formidable)

Commentaire reporté du ticket doublon fermé #4952 > Lors de la modification d'un article qui contient un formulaire avec un champ obligatoire il est impossible d'enregistrer les modifications si elles ont été modifiées en fullscreen. > Le bouton enregistrer est inactif. Workaround : copier les modifs, faire retour à l'article puis modifier dans la page d'édition "normale" > (problème rencontré avec un formulaire formidable)

Par ailleurs il semble que lors de l'insertion d'un formulaire "formidable" il semble qu'il n'y ait pas de balise form insérée...

Par ailleurs il semble que lors de l'insertion d'un formulaire "formidable" il semble qu'il n'y ait pas de balise form insérée...
b_b commented 6 days ago
Owner

Je réouvre le ticket car je confirme sur le master, après quelques recherches je vois que :

  • les données renvoyées par l'action action=porte_plume_previsu comportent bien la balise <form du formulaire présent dans mon article de test
  • par contre, si j'inspecte le contenu de la fenêtre de prévisu je ne trouve aucune trace de la balise form et donc le fix proposé ici ne fonctionne pas.

J'ai logué ce qui passe depuis https://git.spip.net/spip/porte_plume/src/branch/master/javascript/jquery.previsu_spip.js#L145 et j'ai bien la balise form dans data ici https://git.spip.net/spip/porte_plume/src/branch/master/javascript/jquery.previsu_spip.js#L155 mais pas dans le html de la node...

Une piste probable https://stackoverflow.com/questions/36584367/jquery-html-load-stripping-form-tag & https://stackoverflow.com/questions/597596/how-do-you-overcome-the-html-form-nesting-limitation indiquent que si la page est en HTML5 le navigateur retire les balises form imbriquées.

Je réouvre le ticket car je confirme sur le master, après quelques recherches je vois que : - les données renvoyées par l'action `action=porte_plume_previsu` comportent bien la balise `<form` du formulaire présent dans mon article de test - par contre, si j'inspecte le contenu de la fenêtre de prévisu je ne trouve aucune trace de la balise `form` et donc le fix proposé ici ne fonctionne pas. J'ai logué ce qui passe depuis https://git.spip.net/spip/porte_plume/src/branch/master/javascript/jquery.previsu_spip.js#L145 et j'ai bien la balise `form` dans `data` ici https://git.spip.net/spip/porte_plume/src/branch/master/javascript/jquery.previsu_spip.js#L155 mais pas dans le html de la `node`... Une piste probable https://stackoverflow.com/questions/36584367/jquery-html-load-stripping-form-tag & https://stackoverflow.com/questions/597596/how-do-you-overcome-the-html-form-nesting-limitation indiquent que si la page est en HTML5 le navigateur retire les balises `form` imbriquées.
b_b reopened this issue 6 days ago
b_b commented 6 days ago
Owner

Le patch suivant fait le job :)

diff --git a/javascript/jquery.previsu_spip.js b/javascript/jquery.previsu_spip.js
index 9ff84c1..ee2046d 100644
--- a/javascript/jquery.previsu_spip.js
+++ b/javascript/jquery.previsu_spip.js
@@ -155,8 +155,8 @@
 							node.html(data).removeClass('ajaxLoad');
 							//ouvre un nouvel onglet lorsqu'on clique sur un lien dans la prévisualisation
 							$("a",node).attr("target","blank");
-							// passer les forms en novalidate
-							$("form",node).attr("novalidate","novalidate");
+							// virer tous les attributs required des éléments de formulaires
+							$("[required]",node).removeAttr("required");
 						}
 					} );
 				}
Le patch suivant fait le job :) ```diff diff --git a/javascript/jquery.previsu_spip.js b/javascript/jquery.previsu_spip.js index 9ff84c1..ee2046d 100644 --- a/javascript/jquery.previsu_spip.js +++ b/javascript/jquery.previsu_spip.js @@ -155,8 +155,8 @@ node.html(data).removeClass('ajaxLoad'); //ouvre un nouvel onglet lorsqu'on clique sur un lien dans la prévisualisation $("a",node).attr("target","blank"); - // passer les forms en novalidate - $("form",node).attr("novalidate","novalidate"); + // virer tous les attributs required des éléments de formulaires + $("[required]",node).removeAttr("required"); } } ); } ```
Owner

Mais je me demande si en fait il faudrait pas être plus agressif et passer en disabled tous les input/select du html qu'on s'aprête à injecter.

Car sinon si il y a un input avec une règle de validation, ça va bloquer pareil par exemple. Et par ailleurs si la balise form imbriquée est virée, ça veut dire qu'on va retrouver les valeurs du formulaire inséré dans le POST de l'édition, avec potentiellement des conflits et des collisions...

Mais je me demande si en fait il faudrait pas être plus agressif et passer en disabled tous les input/select du html qu'on s'aprête à injecter. Car sinon si il y a un input avec une règle de validation, ça va bloquer pareil par exemple. Et par ailleurs si la balise form imbriquée est virée, ça veut dire qu'on va retrouver les valeurs du formulaire inséré dans le POST de l'édition, avec potentiellement des conflits et des collisions...
Owner

Un truc amusant à faire : mettre <formulaire|editer_article> dans le contenu d'un article et prévisualiser… #inception

Un truc amusant à faire : mettre `<formulaire|editer_article>` dans le contenu d'un article et prévisualiser… #inception
b_b commented 5 days ago
Owner

Car sinon si il y a un input avec une règle de validation, ça va bloquer pareil par exemple.

Tu veux dire une règle de validation basée sur HTML5 ? (je ne savais même pas que c'était possible) / edit ha ben vi https://developer.mozilla.org/fr/docs/Learn/Forms/Form_validation#validation_selon_une_expression_r%C3%A9guli%C3%A8re

Et par ailleurs si la balise form imbriquée est virée, ça veut dire qu'on va retrouver les valeurs du formulaire inséré dans le POST de l'édition

Je viens de vérifier, aucune trace des valeurs correspondantes aux champs du formulaire contact_libre utilisé dans mes tests dans le POST sur ?exec=article_edit lors de la soumission du formulaire editer_article.

> Car sinon si il y a un input avec une règle de validation, ça va bloquer pareil par exemple. Tu veux dire une règle de validation basée sur HTML5 ? (je ne savais même pas que c'était possible) / edit ha ben vi https://developer.mozilla.org/fr/docs/Learn/Forms/Form_validation#validation_selon_une_expression_r%C3%A9guli%C3%A8re > Et par ailleurs si la balise form imbriquée est virée, ça veut dire qu'on va retrouver les valeurs du formulaire inséré dans le POST de l'édition Je viens de vérifier, aucune trace des valeurs correspondantes aux champs du formulaire contact_libre utilisé dans mes tests dans le POST sur `?exec=article_edit` lors de la soumission du formulaire editer_article.
Owner

même sans regex @b_b : ya les champs email qui ne doivent contenir qu'un email par ex, et ça a toujours généré une erreur si html5

même sans regex @b_b : ya les champs email qui ne doivent contenir qu'un email par ex, et ça a toujours généré une erreur si html5
b_b commented 5 days ago
Owner

même sans regex @b_b : ya les champs email qui ne doivent contenir qu'un email par ex, et ça a toujours généré une erreur si html5

Vi vi, à partir du moment où les gens remplissent les champs du form dans la prévisu ça peut devenir bloquant...

> même sans regex @b_b : ya les champs email qui ne doivent contenir qu'un email par ex, et ça a toujours généré une erreur si html5 Vi vi, à partir du moment où les gens remplissent les champs du form dans la prévisu ça peut devenir bloquant...
b_b commented 5 days ago
Owner

Le patch devient donc :

diff --git a/javascript/jquery.previsu_spip.js b/javascript/jquery.previsu_spip.js
index 9ff84c1..287bcf6 100644
--- a/javascript/jquery.previsu_spip.js
+++ b/javascript/jquery.previsu_spip.js
@@ -155,8 +155,8 @@
 							node.html(data).removeClass('ajaxLoad');
 							//ouvre un nouvel onglet lorsqu'on clique sur un lien dans la prévisualisation
 							$("a",node).attr("target","blank");
-							// passer les forms en novalidate
-							$("form",node).attr("novalidate","novalidate");
+							// désactiver tous les éléments de formulaires
+							$(":input",node).attr("disabled","disabled");
 						}
 					} );
 				}

Ça m'aura permis de découvrir https://api.jquery.com/input-selector/ :)

Le patch devient donc : ```diff diff --git a/javascript/jquery.previsu_spip.js b/javascript/jquery.previsu_spip.js index 9ff84c1..287bcf6 100644 --- a/javascript/jquery.previsu_spip.js +++ b/javascript/jquery.previsu_spip.js @@ -155,8 +155,8 @@ node.html(data).removeClass('ajaxLoad'); //ouvre un nouvel onglet lorsqu'on clique sur un lien dans la prévisualisation $("a",node).attr("target","blank"); - // passer les forms en novalidate - $("form",node).attr("novalidate","novalidate"); + // désactiver tous les éléments de formulaires + $(":input",node).attr("disabled","disabled"); } } ); } ``` Ça m'aura permis de découvrir https://api.jquery.com/input-selector/ :)

Je viens de tester sur site en local et ça marche bien. Le form dans la fenêtre de prévisu est complètement désactivé et on enregistre les modifs de texte sans problème.
A passer dans la 4.0.1 ?

Je viens de tester sur site en local et ça marche bien. Le form dans la fenêtre de prévisu est complètement désactivé et on enregistre les modifs de texte sans problème. A passer dans la 4.0.1 ?
Sign in to join this conversation.
No Milestone
No project
No Assignees
6 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.