You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Avec ces articles vous comprendrez (entre autres!) pourquoi **vous rencontrez ce problème**, pourquoi **il faut toujours connaître l'encodage d'un texte** et pourquoi **l'UTF-8 vous sauvra**.
@@ -12,20 +12,20 @@ En HTML, certes, mais lorsque qu'on parle d'application riche en javascript, c'e
12
12
Si vous ne comprenez pas pourquoi le navigateur ne retient pas vos logins, ne propose pas le mot de passe associé, ou ne réagit pas à la touche entrée, lisez la suite !
13
13
14
14
Cet article est le résultat de **l'étude empirique du comportement des navigateurs**.
15
-
Il est donc sujet à caution: tout dépends de votre navigateur, et de sa version.
15
+
Il est donc sujet à caution: tout dépends de votre navigateur et de sa version.
16
16
J'espère simplement vous aider à comprendre et éviter les principaux chausse-trappes, sans avoir recours à l'installation d'un plugin :)
17
17
18
18
19
19
## Mais ce n'est qu'un formulaire !
20
20
21
-
Hélas non... Les formulaire de login (un champs <tt>text</tt> + un champ <tt>password</tt>) sont détecté par le navigateur, qui va traiter différemment des autres champs textuels.
21
+
Hélas non... Les formulaires de login (un champs <tt>text</tt> + un champ <tt>password</tt>) sont détectés par le navigateur, qui va les traiter différemment des autres champs textuels.
22
22
23
23
C'est là le premier problème :
24
24
>**Le formulaire doit être présent dans le DOM au chargement de la page.**
25
25
26
-
Oui, vous avez compris : si vous construisez votre formulaire directement en JS, ou si vous utilisez un template que vous accrochez une fois la page chargée, votre formulaire ne sera ignorés par certains navigateurs.
26
+
Oui, vous avez compris : si vous construisez votre formulaire directement en JS, ou si vous utilisez un template que vous accrochez une fois la page chargée, votre formulaire sera ignoré par certains navigateurs.
27
27
28
-
L'astuce que j'utilise consiste a :
28
+
L'astuce que j'utilise consiste à:
29
29
30
30
* inclure le formulaire de login dans ma page index.html
31
31
* le masquer avec un style CSS <tt>display:none</tt>.
@@ -74,23 +74,23 @@ Même s'il est masqué (le bouton n'est pas encore bien skinnable, même en CSS
74
74
}).button({label:'log in !'});
75
75
76
76
77
-
## Doit-on stopper la propagation de l'évènement <tt>submit</tt> ?
77
+
## Doit-on stopper la propagation de l'événement <tt>submit</tt> ?
78
78
79
-
Le problème se pose si vous ne réalisez pas de "vrai" POST lorsque l'utilisateur déclenche la soumission du formulaire.
80
-
Dans la majorité des applications riches, l'authentification se fait via une Api, et donc un appel Ajax.
79
+
Le problème se pose si vous ne réalisez pas un "vrai" POST lorsque l'utilisateur déclenche la soumission du formulaire.
80
+
Dans la majorité des applications riches, l'authentification se fait via une API, et donc un appel Ajax.
81
81
82
-
On se branche alors sur l'évènement submit, et on annule sa propagation. Par exemple :
82
+
On se branche alors sur l'événement submit, et on annule sa propagation.
83
83
84
-
Seulement, en stoppant l'évènement de soumission, le navigateur ne retient pas le login et le mot de passe.
84
+
Seulement, en stoppant l'événement de soumission, le navigateur ne retient pas le login et le mot de passe.
85
85
86
-
>**Pour que le navigateur mémorise le couple login/mot de passe, l'évènement <tt>submit</tt> doit se propager.**
86
+
>**Pour que le navigateur mémorise le couple login/mot de passe, l'événement <tt>submit</tt> doit se propager.**
87
87
88
88
Cela implique:
89
89
90
-
*Que le formulaire pointe sur une véritable url, sinon, une vilaine 404 apparaitra dans votre console
91
-
*Que le résultat de la soumission est routée dans une iframe (désolé pour les puristes :)), sans quoi, toute la page se rechargera
90
+
*que le formulaire pointe sur une véritable url, sinon, une vilaine 404 apparaitra dans votre console
91
+
*que le résultat de la soumission soit routée dans une iframe (désolé pour les puristes :)), sans quoi, toute la page se rechargera
92
92
93
-
Donc généralement, mon service web propose une Api POST qui ne fait rien et renvoi une page vide, et j'utilise une iframe masquée.
93
+
Donc généralement, mon service web propose une API POST qui ne fait rien et renvoie une page vide, et j'utilise une iframe masquée.
94
94
95
95
**index.html**
96
96
@@ -107,35 +107,37 @@ Donc généralement, mon service web propose une Api POST qui ne fait rien et re
107
107
**login.js**
108
108
109
109
$('#formLogin').submit(function(event){
110
-
// Ici mon appel ajax, et surtout, ne pas renvoyer false ni n'invoquer event.stopPropagation().
110
+
// Ici mon appel ajax, et surtout, ne pas renvoyer false ni invoquer event.stopPropagation().
111
111
});
112
112
113
113
114
114
### Une petite astuce : lorsque l'authentification échoue.
115
115
116
-
A partir du moment où l'évènement <tt>submit</tt> est propagé, et qu'une réponse HTTP est reçue, le navigateur conservera bien le mot de passe et le login.
116
+
A partir du moment où l'événement <tt>submit</tt> est propagé, et qu'une réponse HTTP est reçue, le navigateur conservera bien le mot de passe et le login.
117
117
118
-
Mais nous pouvons tirer parti de se comportement, lorsque l'authentification échoue, par exemple si l'utilisateur est inconnu, ou le mot de passe erroné.
118
+
Mais nous pouvons tirer parti de ce comportement, lorsque l'authentification échoue, par exemple si l'utilisateur est inconnu, ou le mot de passe erroné.
119
119
120
-
Ainsi, mon appel Ajax est toujours **synchrone** (parfois ça sert !), et s'il échoue, alors dans ce cas, j'annule la propagation de l'évènement <tt>submit</tt> pour ne pas conserver les mauvais identifiants.
120
+
Ainsi, mon appel Ajax est toujours **synchrone** (parfois ça sert !), et s'il échoue, alors dans ce cas, j'annule la propagation de l'événement <tt>submit</tt> pour ne pas conserver les mauvais identifiants.
121
121
122
122
123
123
124
124
## La touche entrée ne soumet pas toujours mon formulaire...
125
125
126
-
Hélas oui, c'est un comportement étrange de certains navigateurs : un formulaire sera automatiquement soumit si on appuie sur entrée dans un de ses champs, sauf s'il à plus d'un champ <tt>text</tt>/<tt>password</tt>!
126
+
Hélas oui, c'est un comportement étrange de certains navigateurs : un formulaire sera automatiquement soumit si on appuie sur entrée dans un de ses champs, sauf si le bouton submit est invisible !
127
127
128
-
Nous n'avons donc pas d'autres choix que de gérer nous même en javascript la touche entrée :
128
+
Donc il faut eviter le <tt>display:none</tt> ou le <tt>visibility:hidden</tt> sur le champ.
129
+
Personnellement, je lui affecte une taille de zéro. Vous pouvez aussi le positionner en absolu, en dehors de la zone visible, ou le mettre en dessous d'un autre élément avec le <tt>z-index</tt>
129
130
130
-
**login.js**
131
+
**index.html**
131
132
132
-
$('#formLogin input').keyup(function(event){
133
-
if (event.which == '13' && !event.metaKey) {
134
-
$('#formLogin').submit();
135
-
// Annule la propagation de l'évènement clavier, pour ne pas soumettre 2 fois le formulaire sur les navigateurs qui supportent correctement la feature.
0 commit comments