Comment désactiver la saisie semi-automatique du navigateur sur le champ de formulaire Web / la balise de saisie?

2793

Comment désactivez-vous autocompletedans les principaux navigateurs pour un input(ou form field) spécifique ?

Brett Veenstra
la source
2
Dans certains systèmes où les testeurs doivent entrer manuellement de nombreuses informations encore et encore, il peut être utile d'avoir l'option configurable pour que lors du test, vous puissiez la désactiver et appuyer simplement sur 'tab> flèche vers le bas> onglet> flèche vers le bas, etc. . '
Simon_Weaver

Réponses:

2626

Firefox 30 ignore les autocomplete="off"mots de passe, optant plutôt pour demander à l'utilisateur si le mot de passe doit être stocké sur le client. Notez le commentaire suivant du 5 mai 2014:

  • Le gestionnaire de mots de passe demande toujours s'il souhaite enregistrer un mot de passe. Les mots de passe ne sont pas enregistrés sans l'autorisation de l'utilisateur.
  • Nous sommes le troisième navigateur à implémenter ce changement, après IE et Chrome.

Selon la documentation de Mozilla Developer Network , l'attribut d'élément de formulaire booléen autocompleteempêche la mise en cache des données de formulaire dans les anciens navigateurs.

<input type="text" name="foo" autocomplete="off" />
nlucaroni
la source
45
Cela n'a pas fonctionné pour moi dans Firefox 3.0.3 J'ai dû mettre l'attribut de saisie semi-automatique dans le FORM plutôt que dans l'ENTRÉE.
Winston Fassett
17
La saisie semi-automatique n'est définie que dans les normes HTML 5, elle interrompra donc toutes les validations que vous exécutez avec HTML 4. * ...
Jrgns
96
@Winston, vous devez le mettre à la fois sur le formulaire ET sur l'élément d'entrée lui-même. De cette façon, vous couvrez toute la non-standardité des navigateurs.
AviD
83
Et n'oubliez pas de désactiver votre saisie semi - automatique = sur l' extension (si vous utilisez Chrome) avant de tester votre application Web. Sinon, vous vous sentirez vraiment idiot comme moi. ;)
Jo Liss
314

De plus autocomplete=off, vous pouvez également faire en sorte que les noms de vos champs de formulaire soient randomisés par le code qui génère la page, peut-être en ajoutant une chaîne spécifique à la session à la fin des noms.

Lorsque le formulaire est soumis, vous pouvez retirer cette partie avant de la traiter côté serveur. Cela empêcherait le navigateur Web de trouver le contexte de votre champ et pourrait également empêcher les attaques XSRF car un attaquant ne pourrait pas deviner les noms de champ pour une soumission de formulaire.

Ben Combee
la source
10
C'est une bien meilleure solution que l'utilisation de la saisie semi-automatique = "off". Tout ce que vous avez à faire est de générer un nouveau nom à chaque chargement de page et d'enregistrer ce nom dans une $ _SESSION pour une utilisation future:$_SESSION['codefield_name'] = md5(uniqid('auth', true));
améliorez
78
Non, ce n'est pas une meilleure solution, car l'origine de préférence pour ce paramètre est l'agent utilisateur également connu sous le nom de navigateur Web. Il existe une différence entre la prise en charge de certains comportements (ce que HTML 5 tente de faire) et le forçage en décidant au nom de l'utilisateur, ce qui, selon vous, est une "bien meilleure solution".
amn
15
Cette solution peut fonctionner avec tous les navigateurs, donc à cet égard, elle est "meilleure". Néanmoins, amn a raison, décider de désactiver la saisie semi-automatique au nom de vos utilisateurs n'est pas une bonne idée. Cela signifie que je ne désactiverais la saisie semi-automatique que dans des situations très spécifiques, comme lorsque vous prévoyez de créer votre propre fonctionnalité de saisie semi-automatique et que vous ne souhaitez pas de conflits ou de comportements étranges.
macguru2000
8
En ce qui concerne les attaques XSRF, je ne sais pas quel type d'attaque vous représentiez, mais l'attaquant ne pourrait-il pas simplement retirer la partie finale de la même manière que vous le faites côté serveur pour identifier les champs? Ou si l'attaquant publie les champs, ne pourrait-il pas ajouter sa propre chaîne aléatoire car elle sera supprimée par le serveur?
xr280xr
9
@ macguru2000 créer votre propre saisie semi-automatique est un cas d'utilisation tout à fait légitime et courant. Vraiment, le navigateur devrait permettre aux développeurs de désactiver plus facilement la saisie semi-automatique quand ils en ont besoin au lieu de nous forcer à utiliser des hacks comme celui-ci
whoadave
235

La plupart des principaux navigateurs et gestionnaires de mots de passe (correctement, à mon humble avis) ignorent maintenant autocomplete=off.

Pourquoi? De nombreuses banques et autres sites Web de «haute sécurité» ont été ajoutés autocomplete=offà leurs pages de connexion «à des fins de sécurité», mais cela diminue en fait la sécurité car cela permet aux gens de changer les mots de passe sur ces sites à haute sécurité pour être faciles à mémoriser (et donc à casser) depuis la saisie semi-automatique a été cassé.

Il y a longtemps, la plupart des gestionnaires de mots de passe ont commencé à ignorer autocomplete=off, et maintenant les navigateurs commencent à faire de même pour les entrées de nom d'utilisateur / mot de passe uniquement.

Malheureusement, des bogues dans les implémentations de saisie semi-automatique insèrent des informations de nom d'utilisateur et / ou de mot de passe dans des champs de formulaire inappropriés, provoquant des erreurs de validation de formulaire, ou pire encore, insérant accidentellement des noms d'utilisateur dans des champs qui ont été intentionnellement laissés vides par l'utilisateur.

Que doit faire un développeur web?

  • Si vous pouvez conserver tous les champs de mot de passe sur une page par eux-mêmes, c'est un bon début car il semble que la présence d'un champ de mot de passe soit le principal déclencheur de la saisie semi-automatique utilisateur / passe. Sinon, lisez les conseils ci-dessous.
  • Safari remarque qu'il y a 2 champs de mot de passe et désactive la saisie semi-automatique dans ce cas, en supposant qu'il doit s'agir d'un formulaire de changement de mot de passe, pas d'un formulaire de connexion. Assurez-vous donc d'utiliser 2 champs de mot de passe (nouveau et confirmez nouveau) pour tous les formulaires où vous autorisez
  • Chrome 34, malheureusement, essaiera de remplir automatiquement les champs avec user / pass chaque fois qu'il verra un champ de mot de passe. C'est un assez mauvais bug qui, espérons-le, changera le comportement de Safari. Cependant, l'ajout de cela en haut de votre formulaire semble désactiver la saisie automatique du mot de passe:

    <input type="text" style="display:none">
    <input type="password" style="display:none">

Je n'ai pas encore étudié en détail IE ou Firefox, mais je serai heureux de mettre à jour la réponse si d'autres ont des informations dans les commentaires.

apinstein
la source
5
que voulez-vous dire par "l'ajout de ceci sur votre page semble désactiver la saisie automatique pour la page:"
wutzebaer
5
@wutzebaer, Chrome remarque le champ de mot de passe caché et arrête la saisie semi-automatique. Il semblerait que cela vise à empêcher le site de voler des informations de mot de passe sans que l'utilisateur ne s'en rende compte.
David W
6
Votre extrait de code empêche la saisie semi-automatique des champs de connexion sur Chrome, Firefox, IE 8 et IE 10. N'a pas testé IE 11. Bon! Seule réponse simple qui fonctionne toujours.
Sam Watkins
3
Votre note de safari semble également fonctionner sur Chrome, au moins depuis décembre 2015. J'avais un champ de nom d'utilisateur et de mot de passe sur un formulaire d'inscription qui se complétait automatiquement avec les données du formulaire de connexion. La création de deux type='password'champs sur la même page a entraîné l'ignorance de la saisie semi-automatique du «mot de passe» du navigateur, ce qui était tout à fait logique car les formulaires d'inscription ont tendance à demander le mot de passe deux fois alors que les formulaires de connexion ne le demandent qu'une seule fois.
Matt Fletcher
3
Ne semble plus fonctionner dans Chrome 55, sauf si le champ de mot de passe supplémentaire n'est pas masqué, ce qui va à l'encontre de l'objectif.
jokkedk
160

Parfois, même la saisie semi-automatique = off n'empêcherait pas de remplir les informations d'identification dans des champs incorrects, mais pas le champ utilisateur ou surnom.

Cette solution de contournement s'ajoute à la publication d'Apinstein sur le comportement du navigateur.

correction du remplissage automatique du navigateur en lecture seule et mise en écriture sur le focus (clic et onglet)

 <input type="password" readonly  
     onfocus="this.removeAttribute('readonly');"/>

Mise à jour: Mobile Safari place le curseur dans le champ, mais n'affiche pas le clavier virtuel. Le nouveau correctif fonctionne comme avant mais gère le clavier virtuel:

<input id="email" readonly type="email" onfocus="if (this.hasAttribute('readonly')) {
    this.removeAttribute('readonly');
    // fix for mobile safari to show virtual keyboard
    this.blur();    this.focus();  }" />

Démo en direct https://jsfiddle.net/danielsuess/n0scguv6/

// UpdateEnd

Parce que le navigateur remplit automatiquement les informations d'identification dans un champ de texte incorrect!?

Je remarque ce comportement étrange sur Chrome et Safari, quand il y a des champs de mot de passe sous la même forme. Je suppose que le navigateur recherche un champ de mot de passe pour insérer vos informations d'identification enregistrées. Ensuite, il remplit automatiquement (juste en devinant en raison d'une observation) le champ de saisie de texte le plus proche, qui apparaît avant le champ de mot de passe dans DOM. Comme le navigateur est la dernière instance et que vous ne pouvez pas le contrôler,

Cette correction en lecture seule ci-dessus a fonctionné pour moi.

dsuess
la source
8
S'il n'y a pas de javascript, alors le formulaire entier échoue. -1
Jimmy Kane
8
@JimmyKane, la clé serait d'ajouter également l'attribut en utilisant javascript en premier lieu (ce que dsuess n'a pas fait ici, mais en ajoutant simplement pour être complet).
trnelson
@tmelson Je comprends, mais pourquoi utiliser js pour désactiver même? Evitons js pour les choses qui peuvent être améliorées nativement. Encore une fois, je suis d'accord avec vous.
Jimmy Kane
3
Cela ne fonctionne pas correctement dans IE8, le champ de mot de passe en lecture seule n'est pas modifiable la première fois que vous le concentrez, seulement après que vous l'avez fait et que vous vous êtes à nouveau concentré. Bonne idée, mais malheureusement c'est un peu trop hacky et pas sûr à utiliser.
Sam Watkins
Cela ne fonctionne pas correctement sur tous les navigateurs (par exemple IE 11 et IE Edge). Dès que le readonlyest supprimé, la sélection ultérieure du champ entraîne le retour de la saisie semi-automatique.
Fin du codage
106
<form name="form1" id="form1" method="post" 
      autocomplete="off" action="http://www.example.com/form.cgi">

Cela fonctionnera dans Internet Explorer et Mozilla FireFox, l'inconvénient est qu'il n'est pas standard XHTML.

brendan
la source
J'ai remarqué que l'ajouter à l'élément de formulaire ne l'empêche pas toujours d'être appliqué aux entrées individuelles du formulaire. Par conséquent, il est probablement préférable de le placer directement sur l'élément d'entrée.
sholsinger
15
En fait @sholsinger, il est préférable de le mettre à la fois sur le formulaire ET sur l'élément d'entrée lui-même. De cette façon, vous couvrez toute la non-standardité des navigateurs.
AviD
2
Malheureusement, depuis IE 11, Microsoft ne respecte plus cela input type="password". Espérons qu'aucun autre navigateur ne choisisse de supprimer cette fonctionnalité.
SamHuckaby
La configuration autocomplete="off"sur le formest la seule chose qui a fonctionné pour Chrome.
Andrew
106

La solution pour Chrome consiste à ajouter autocomplete="new-password"au mot de passe du type d'entrée. Veuillez vérifier l'exemple ci-dessous.

Exemple:

<form name="myForm"" method="post">
   <input name="user" type="text" />
   <input name="pass" type="password" autocomplete="new-password" />
   <input type="submit">
</form>

Chrome remplit toujours automatiquement les données s'il trouve une boîte de type mot de passe , juste assez pour indiquer cette boîte autocomplete = "new-password".

Cela fonctionne bien pour moi.

Remarque: assurez-vous F12que vos modifications prennent effet, plusieurs fois les navigateurs enregistrent la page en cache, cela m'a donné une mauvaise impression que cela ne fonctionnait pas, mais le navigateur n'a pas réellement apporté les modifications.

Geynen
la source
2
Cela fonctionne également dans Chrome pour d'autres types de champs, pas seulement pour type = "mot de passe".
Jake
Je l'ai utilisé avec des types de mot de passe, de messagerie et de texte et cela a fonctionné. Je l'ai utilisé simplement comme ceci: autocomplete = "new"
Crak_mboutin
autocomplete = "nope" name = "pswd" et utilisé <input name = "dummyPassword" type = "password" style = "display: none;"> avant le champ de saisie du vrai mot de passe. Cela a fonctionné pour moi.
Denuka
Cela fonctionne maintenant dans presque tous les navigateurs, pas seulement dans Chrome: autocomplete # Browser_compatibility .
Andrew Morton
60

Comme d’autres l’ont dit, la réponse est autocomplete="off"

Cependant, je pense qu'il vaut la peine d'indiquer pourquoi c'est une bonne idée de l'utiliser dans certains cas, car certaines réponses à cette question et des questions en double ont suggéré qu'il est préférable de ne pas la désactiver.

L'arrêt des navigateurs stockant des numéros de carte de crédit ne doit pas être laissé aux utilisateurs. Trop d'utilisateurs ne réaliseront même pas que c'est un problème.

Il est particulièrement important de le désactiver dans les champs des codes de sécurité des cartes de crédit. Comme l'indique cette page :

"Ne stockez jamais le code de sécurité ... sa valeur dépend de la présomption que le seul moyen de le fournir est de le lire à partir de la carte de crédit physique, prouvant que la personne qui le fournit détient effectivement la carte."

Le problème est que s'il s'agit d'un ordinateur public (cybercafé, bibliothèque, etc.), il est alors facile pour les autres utilisateurs de voler les détails de votre carte, et même sur votre propre machine, un site Web malveillant pourrait voler des données de saisie semi-automatique .

Sam Hasler
la source
7
si j'allais sur un site et qu'il se souvenait de ma carte dans la liste déroulante, je serais très mécontent. Je commence à me demander comment ils pourraient être si insouciants.
Simon_Weaver
9
Cas beaucoup plus simple / plus critique. Lorsque je visite la page d'un utilisateur dans la partie admin de mon site, il essaie de définir son nom d'utilisateur et mon mot de passe pour être mon nom d'utilisateur et mon mot de passe administrateur, sans pouvoir dire que ce n'est pas un formulaire de connexion. Je veux que mon mot de passe administrateur soit mémorisé, mais c'est une erreur critique qu'il essaie d'appliquer ce nom d'utilisateur / mot de passe mémorisé à tous les utilisateurs que je modifie ensuite.
rjmunro
34

J'ai résolu le combat sans fin avec Google Chrome avec l'utilisation de caractères aléatoires. Lorsque vous effectuez toujours un rendu de saisie semi-automatique avec une chaîne aléatoire, il ne se souviendra de rien.

<input name="name" type="text" autocomplete="rutjfkde">

J'espère que cela aidera d'autres personnes.

étape
la source
2
Cela fonctionne encore mieux. Vous pouvez ajouter un petit JS qui génère un code aléatoire pour chaque chargement de page et ajouter ce code au champ de saisie: <code> function autoId () {var autoId = ""; var dict = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"; for (var i = 0; i <12; i ++) {autoId + = dict.charAt (Math.floor (Math.random () * dict.length)); } return autoId; } $ ('. autocompleteoff'). attr ('autocomplete', autoId ()); </code> Vous pouvez ajouter la autocompleteoffclasse au champ de saisie souhaité.
Raghuram Kasyap
ne fonctionne pas dans ma version Chrome 68.0.3440.106 (version officielle) (64 bits)
Sukanya Purushothaman
Chrome a été corrigé pour utiliser le "off" standardisé maintenant
MacK
1
Malheureusement, cela fonctionne mieux que ce qu'on appelle standard sur le chrome
Nour Lababidi
1
Aujourd'hui, j'ai découvert que Chrome écraserait une chaîne aléatoire avec "Off". Je ne peux pas croire que les développeurs Chrome font cet attribut mauvais et non contrôlé. Pourquoi ohh mon obtenu.
étape
33

Je dois mendier pour différer avec ces réponses qui disent d'éviter de désactiver la saisie semi-automatique.

La première chose à signaler est que la saisie semi-automatique n'étant pas explicitement désactivée dans les champs du formulaire de connexion est un échec PCI-DSS. De plus, si la machine locale d'un utilisateur est compromise, toutes les données de saisie semi-automatique peuvent être obtenues de manière triviale par un attaquant car elles sont stockées en clair.

Il y a certainement un argument en faveur de l'utilisabilité, mais il y a un très bon équilibre quand il s'agit de savoir quels champs du formulaire doivent avoir la saisie semi-automatique désactivée et lesquels ne doivent pas.

Securatek
la source
Il vient juste de mon attention que IE ne déclenche pas d'événements onChange lorsque vous remplissez une entrée de texte à l'aide de la saisie semi-automatique. Nous avons des dizaines de formulaires et plus d'un millier d'événements onChange (validations d'entrée, logique métier) éparpillés partout. Récemment, nous avons mis à niveau IE vers une version plus récente et tout d'un coup, des choses étranges ont commencé à se produire. Heureusement, nous exécutons une application intranet et la saisie semi-automatique n'est pas un problème UX pour nous, il est plus facile de simplement la désactiver.
Robotron
3
Si la machine locale d'un utilisateur est compromise, elle est vissée, point final. Il pourrait avoir un enregistreur de frappe installé, il pourrait y avoir un faux certificat racine SSL ajouté et tout envoyé via un faux proxy, etc. cet utilisateur mon nom d'utilisateur et mot de passe administrateur. Je dois empêcher ce comportement.
rjmunro
1
Les fournisseurs de navigateurs semblent chercher leurs propres intérêts. Mots de passe enregistrés = verrouillage de l'utilisateur. Et la saisie semi-automatique activée / désactivée était trop simple - pourquoi pas une norme complexe d'indices sémantiques ( html.spec.whatwg.org/multipage/… ) qui, en passant, permet au navigateur de collecter de précieuses données sémantiques sur les sites chacun visites d'utilisateurs?
aro_tech
le cas d'utilisation spécifique que j'essaie de résoudre est le suivant: ils sont déjà connectés. mais maintenant ils sont sur le point d'accéder à quelque chose de plus sensible. Je veux montrer un dialogue qui les fait se réauthentifier, contre la possibilité qu'ils soient partis pour fumer et qu'une mauvaise personne s'est assise sur leur chaise. ont essayé plusieurs techniques pour vaincre l'auto-complétion, et rien ne fonctionne. maintenant je pense, peut-être, au moins, utiliser le bon vieux 'password = window.prompt ("Veuillez ressaisir votre mot de passe")' plus le nom d'utilisateur dans la session, et essayer de l'authentifier.
David
31

Trois options: Première:

<input type='text' autocomplete='off' />

Seconde:

<form action='' autocomplete='off'>

Troisième (code javascript):

$('input').attr('autocomplete', 'off');
yajay
la source
2
Les première et deuxième options devraient être une option, car elles varient selon la façon dont les navigateurs gèrent cela.
rybo111
Tentative $ formElement.attr ('autocomplete', 'off'); et ça ne marche pas.
Ben Sinclair
22

Sur un sujet apparenté ou en fait, sur une note complètement opposée -

"Si vous êtes l'utilisateur du formulaire susmentionné et que vous souhaitez réactiver la fonctionnalité de saisie semi-automatique, utilisez le bookmarklet" mémoriser le mot de passe "de cette page de bookmarklets . Il supprime tous les autocomplete="off"attributs de tous les formulaires de la page. Continuez à combattre le bon combat! "

Antti Kissaniemi
la source
20

Nous avons effectivement utilisé l 'idée de sasb pour un site. C'était une application Web de logiciel médical pour gérer le cabinet d'un médecin. Cependant, beaucoup de nos clients étaient des chirurgiens qui utilisaient de nombreux postes de travail différents, y compris des terminaux semi-publics. Ainsi, ils voulaient s'assurer qu'un médecin qui ne comprend pas l'implication des mots de passe enregistrés automatiquement ou qui n'y prête pas attention ne peut pas accidentellement laisser ses informations de connexion facilement accessibles. Bien sûr, c'était avant l'idée de la navigation privée qui commence à apparaître dans IE8, FF3.1, etc. Néanmoins, de nombreux médecins sont obligés d'utiliser des navigateurs de la vieille école dans les hôpitaux avec des TI qui ne changeront pas.

Nous avons donc eu la page de connexion générer des noms de champs aléatoires qui ne fonctionneraient que pour cette publication. Oui, c'est moins pratique, mais cela ne fait que frapper la tête de l'utilisateur de ne pas stocker les informations de connexion sur les terminaux publics.

Jon Adams
la source
20

Aucune des solutions n'a fonctionné pour moi dans cette conversation.

J'ai finalement trouvé une solution HTML pure qui ne nécessite pas de Javascript , fonctionne dans les navigateurs modernes (sauf IE; il fallait au moins 1 capture, non?), Et ne vous oblige pas à désactiver la saisie semi-automatique pour l'ensemble du formulaire.

Désactivez simplement la saisie semi-automatique sur le form, puis activez-le pour tout inputce que vous souhaitez qu'il fonctionne dans le formulaire. Par exemple:

<form autocomplete="off">
    <!-- these inputs will not allow autocomplete and chrome 
         won't highlight them yellow! -->
    <input name="username"  />
    <input name="password" type="password" />
    <!-- this field will allow autocomplete to work even 
         though we've disabled it on the form -->
    <input name="another_field" autocomplete="on" />
</form>
lifo
la source
C'était totalement ce que je cherchais!
Marco
20

Réglez juste autocomplete="off". Il y a une très bonne raison à cela: vous voulez fournir votre propre fonctionnalité de saisie semi-automatique!

En dangerMassa
la source
20

J'ai essayé des solutions sans fin, puis j'ai trouvé ceci:

Au lieu d' autocomplete="off"utiliser simplementautocomplete="false"

Aussi simple que cela, et cela fonctionne aussi comme un charme dans Google Chrome!

Kaszoni Ferencz
la source
Comme vous l'avez dit en chrome, la valeur off ne fonctionne pas. Il doit être "faux"
azuax
Fonctionne pour moi sur Chrome 44.0.2403.130.
GuiGS
1
J'ai essayé ceci: $ formElement.attr ('autocomplete', 'false'); désolé ne fonctionne pas.
Ben Sinclair
20

Cela fonctionne pour moi.

<input name="pass" type="password" autocomplete="new-password" />

Nous pouvons également utiliser cette stratégie dans d'autres contrôles comme le texte, sélectionnez etc.

Muhammad Awais
la source
ce devrait être la dernière réponse. la seule réponse qui fonctionne pour moi dans le dernier chrome
Nick Chan Abdullah
19

Je pense que autocomplete=offc'est pris en charge dans HTML 5.

Demandez-vous cependant pourquoi vous voulez faire cela - cela peut avoir du sens dans certaines situations, mais ne le faites pas uniquement pour le faire.

C'est moins pratique pour les utilisateurs et ce n'est même pas un problème de sécurité sous OS X (mentionné par Soren ci-dessous). Si vous craignez que des personnes se voient voler leur mot de passe à distance - un enregistreur de frappe peut toujours le faire même si votre application l'utilise autcomplete=off.

En tant qu'utilisateur qui choisit d'avoir un navigateur se souvient (la plupart) de mes informations, je trouverais ennuyeux si votre site ne se souvenait pas des miennes.

user631300
la source
17

En plus de

autocomplete="off"

Utilisation

readonly onfocus="this.removeAttribute('readonly');"

pour les entrées que vous ne voulez pas de se rappeler des données de formulaire ( username, password, etc.) comme indiqué ci - dessous:

<input type="text" name="UserName" autocomplete="off" readonly 
    onfocus="this.removeAttribute('readonly');" >

<input type="password" name="Password" autocomplete="off" readonly 
    onfocus="this.removeAttribute('readonly');" >

J'espère que cela t'aides.

Murat Yıldız
la source
1
Pour moi dans IE11, je ne peux pas taper dans la zone de texte même après que onfocus ait supprimé l'attribut en lecture seule. Cependant, si je clique une deuxième fois sur la zone de texte, je peux taper.
mcallahan
J'ai rencontré le même problème avec IE11 (je ne peux pas taper avant le deuxième focus). L'ajout d'un flou puis d'une nouvelle mise au point fonctionne. $(document).on('focus', 'input:password[readonly="readonly"]', function () { $(this).prop('readonly', false).blur().focus(); });
palmsey
@Andrew Bien sûr, vous le pouvez. C'est le principe de base pour surmonter ce problème et j'ai également ajouté une mise à jour contenant un exemple de code complet;)
Murat Yıldız
J'ai également ajoutéonfocusout="this.setAttribute('readonly', 'readonly');"
rinatdobr
16

La meilleure solution:

Empêcher le nom d'utilisateur (ou e-mail) et le mot de passe de saisie semi-automatique:

<input type="email" name="email"><!-- Can be type="text" -->
<input type="password" name="password" autocomplete="new-password">

Empêcher la saisie semi-automatique d'un champ:

<input type="text" name="field" autocomplete="nope">

Explication: autocompletecontinue de fonctionner dans <input>, autocomplete="off"ne fonctionne pas, mais vous pouvez passer offà une chaîne aléatoire, comme nope.

Travaille dans:

  • Chrome: 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63 et 64

  • Firefox: 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57 et 58

Cava
la source
2
J'ai trouvé que cela fonctionnait dans mes tests préliminaires. Tellement étrange que "off" ne fonctionne pas.
Craig Jacobs
Cela ne fonctionne pas pour Chrome sur Android. J'ai essayé de définir des valeurs de chaîne pour l' autocompleteattribut et il affiche toujours les entrées précédentes sous forme de suggestions de saisie semi-automatique sous l'entrée.
tebs1200
@ tebs1200 Lequel? Le champ de mot de passe ou le champ de texte?
Cava
@Cava désolé pour la réponse retardée. Le champ de texte. Peu importe la valeur que je fixe autocomplete, je reçois toujours une liste déroulante de suggestions basée sur les valeurs entrées précédemment. C'est bien sur le bureau, mais pas sur Android Chrome.
tebs1200
14

Un peu tard pour le jeu ... mais je suis juste tombé sur ce problème et j'ai essayé plusieurs échecs, mais celui-ci fonctionne pour moi trouvé sur MDN

Dans certains cas, le navigateur continuera de suggérer des valeurs de saisie semi-automatique même si l'attribut de saisie semi-automatique est désactivé. Ce comportement inattendu peut être assez déroutant pour les développeurs. L'astuce pour forcer vraiment le non-achèvement est d'assigner une chaîne aléatoire à l'attribut comme ceci:

autocomplete="nope"
AAH-Shoot
la source
13

Ajout du

autocomplete="off"

à la balise de formulaire désactivera la saisie semi-automatique du navigateur (ce qui a été précédemment tapé dans ce champ) de tous les inputchamps de ce formulaire particulier.

Testé sur:

  • Firefox 3.5, 4 BETA
  • Internet Explorer 8
  • Chrome
Hacher
la source
13

L'ajout autocomplete="off"ne va pas le couper.

Remplacez l'attribut de type d'entrée par type="search".
Google n'applique pas le remplissage automatique aux entrées avec un type de recherche.

Matas Vaitkevicius
la source
4
C'est un hack. Le champ n'est pas un champ de recherche. À l'avenir, cela pourrait causer des problèmes.
Roel
12

Utilisez un nom et un identifiant non standard pour les champs, donc plutôt que "nom", ayez "nom_". Les navigateurs ne le verront alors pas comme étant le champ du nom. La meilleure partie à ce sujet est que vous pouvez le faire pour certains mais pas tous les champs et il remplira automatiquement certains mais pas tous les champs.

Teifion
la source
Le problème avec cela est que si d'autres sites utilisent "nom_" pour atteindre le même objectif, vous êtes de retour à la case départ.
ConroyP
3
alors faites-le "mysite_name". Si quelqu'un d'autre utilise cela, je leur poserais des questions ...
Steve Perks
cela gâche certains de ces utilitaires de
remplissage
12

Afin d'éviter le XHTML non valide, vous pouvez définir cet attribut à l'aide de javascript. Exemple utilisant jQuery:

<input type="text" class="noAutoComplete" ... />

$(function() {
    $('.noAutoComplete').attr('autocomplete', 'off');
});

Le problème est que les utilisateurs sans javascript obtiendront la fonctionnalité de saisie semi-automatique.

cherouvim
la source
38
cela n'évite pas le xhtml invalide, il ajoute simplement dynamiquement le bit invalide après l'avoir vérifié, il l'a déclaré valide!
Andiih
@Andiih: Existe-t-il un moyen de faire fonctionner la saisie semi-automatique en xhtml?
cherouvim
1
Travaillez (ou arrêtez de travailler ce qui est le but): oui comme ci-dessus. Mais valide - non.
Andiih
11

essayez-les aussi si autocomplete="off"cela ne fonctionne pas:

autocorrect="off" autocapitalize="off" autocomplete="off"
Jeff
la source
11

Je ne peux pas croire que c'est toujours un problème si longtemps après qu'il a été signalé. Les solutions ci-dessus n'ont pas fonctionné pour moi, car safari semblait savoir quand l'élément n'était pas affiché ou hors écran, mais les suivantes ont fonctionné pour moi:

<div style="height:0px; overflow:hidden; ">
  Username <input type="text" name="fake_safari_username" >
  Password <input type="password" name="fake_safari_password">
</div>

J'espère que c'est utile pour quelqu'un!

Ben
la source
1
donc, mettre cela avant que les champs de nom d'utilisateur et de mot de passe ne fonctionnent? le navigateur a rempli ceux-ci et non les vrais
Andrew
11

Voici donc:

function turnOnPasswordStyle() {
  $('#inputpassword').attr('type', "password");
}
<input oninput="turnOnPasswordStyle()" id="inputpassword" type="text">

Stav Bodik
la source
1
Cela semble être une bonne idée si les zones de texte de style empêchent le flash du mot de passe visible.
Andrew
1
Merci beaucoup, cela a fait le travail +1, ma variante de votre solution était de le faire en une seule ligne: <input oninput = "this.type = 'password'" id = "inputpassword" type = "text">
Hasnaa Ibraheem
@HasnaaIbraheem Merci (: parfois plus lisible, c'est mieux.
Stav Bodik
11

Il s'agit d'un problème de sécurité que les navigateurs ignorent maintenant. Les navigateurs identifient et stockent le contenu à l'aide de noms d'entrée, même si les développeurs considèrent que les informations sont sensibles et ne doivent pas être stockées. Faire un nom d'entrée différent entre 2 requêtes résoudra le problème (mais sera toujours enregistré dans le cache du navigateur et augmentera également le cache du navigateur). Demander à l'utilisateur d'activer ou de désactiver des options dans les paramètres de son navigateur n'est pas une bonne solution. Le problème peut être résolu dans le backend.

Voici ma solution. Une approche que j'ai mise en place dans mon cadre. Tous les éléments de saisie semi-automatique sont générés avec une entrée cachée comme celle-ci:

<? $r = rmd5(rand().mocrotime(TRUE)); ?>
<form method="POST" action="./">
    <input type="text" name="<? echo $r; ?>" />
    <input type="hidden" name="__autocomplete_fix_<? echo $r; ?>" value="username" />
    <input type="submit" name="submit" value="submit" />
</form>

Le serveur traite ensuite les variables de publication comme ceci:

foreach ($_POST as $key => $val)
{
    if(preg_match('#^__autocomplete_fix_#', $key) === 1){
        $n = substr($key, 19);
        if(isset($_POST[$n]))$_POST[$val] = $_POST[$n];
    }
}

La valeur est accessible comme d'habitude

var_dump($_POST['username']);

Et le navigateur ne sera pas en mesure de suggérer des informations de la demande précédente ou des utilisateurs précédents.

Tout fonctionne comme un charme, même si les navigateurs se mettent à jour, veulent ignorer la saisie semi-automatique ou non. Cela a été la meilleure façon de résoudre le problème pour moi.

Simmoniz
la source
10

Aucun des hacks mentionnés ici n'a fonctionné pour moi dans Chrome. Il y a une discussion du problème ici: https://code.google.com/p/chromium/issues/detail?id=468153#c41

Ajout de cela à l'intérieur d'une <form>œuvre (au moins pour l'instant):

<div style="display: none;">
    <input type="text" id="PreventChromeAutocomplete" name="PreventChromeAutocomplete" autocomplete="address-level4" />
</div>
Jakob Løkke Madsen
la source
1
Notez qu'en utilisant cette technique, FireFox remplira toujours réellement ce champ caché, qui sera inclus lors de la soumission du formulaire. Ce serait probablement mauvais, car le mot de passe serait alors transféré sur une connexion potentiellement non sécurisée. Heureusement, l'ajout maxlength="0"empêche Firefox de remplir automatiquement le champ.
Mikal Schacht Jensen
9

Vous pouvez utiliser en entrée.

Par exemple;

<input type=text name="test" autocomplete="off" />
xxxxx
la source