Comment puis-je prévenir la touche retour arrière de naviguer de nouveau?
Sur IE je peux le faire avec l' (terriblement non-standard, mais de travail) jQuery
if ($.browser.msie)
$(document).keydown(function(e) { if (e.keyCode == 8) window.event.keyCode = 0;});
Mais est-il possible de le faire d'une manière qui fonctionne sur Firefox, ou une manière de croix-navigateur pour un bonus?
Pour l'enregistrement:
$(document).keydown(function(e) { if (e.keyCode == 8) e.stopPropagation(); });
ne fait rien.
$(document).keydown(function(e) { if (e.keyCode == 8) e.preventDefault(); });
résout le problème, mais rend la touche retour arrière inutilisable sur la page, ce qui est encore pire que l'original comportement.
EDIT:
La raison pour laquelle je fais c'est que je ne suis pas la création d'une page web simple mais d'une grande application. Il est incroyablement ennuyeux de perdre 10 minutes de travail juste parce que vous avez appuyé sur la touche retour arrière dans le mauvais endroit. Le ratio de la prévention des erreurs vs ennuyeux, les utilisateurs doivent être au-dessus de 1000/1 par la prévention de la touche retour arrière de naviguer de nouveau.
EDIT2: je suis pas d'essayer d'empêcher l'histoire de la navigation, seulement les accidents.
EDIT3: @brentonstrines commentaire (déplacé ici car la question est tellement populaire): C'est un long-terme de "réparer", mais vous pouvez jeter votre soutien derrière le Chrome bug pour modifier ce comportement dans webkit
- Pourquoi voulez-vous faire cela? Les raccourcis clavier sont importants pour les utilisateurs de puissance et les handicapés comme aux utilisateurs d'utiliser efficacement votre site.
- Idem; c'est un peu une chose étrange à faire... sauf si vous avez quelques cas TRÈS spécifiques à l'utilisation de la touche retour arrière de votre application et de piégeage ont été pour vous-même. Si vous essayez de désactiver la fonctionnalité arrière dans l'historique du navigateur, je ne crois pas qu'il existe un moyen de façon fiable (ou autre?) le faire.
- Parce que la touche retour arrière est surchargé. Vous pourriez ne pas avoir remarqué, mais vous avez probablement l'utiliser tout le temps pour effacer les lettres que vous venez de saisir dans un champ de texte. Certains de mes clients ont eu de la difficulté avec qui causer de la page pour revenir, donc c'est une information utile. Personne, mais vous clowns sait que le retour arrière est censé remonter d'une page. C'est quelque chose que je n'ai jamais su, et c'est carrément hostile comportement d'un navigateur à avoir. Je pense que toutes les pages doivent désactiver ce comportement.
- Pourquoi les gens pense que c'est bizarre? À l'aide de la touche retour arrière pour la navigation est vraiment stupide de raccourci! il ya tellement de nombreux champs de texte que les utilisateurs pourraient vouloir supprimer du texte à partir d'imaginer une SORTE de réponse, le passage à une autre fenêtre pour vérifier quelque chose, et puis vous revenez et mis-cliquez sur la zone d'édition, appuyez sur retour arrière pour supprimer un mot et tout à coup le navigateur une page et que vous avez peut-être perdu tout ce que vous venez d'écrire.
- Pourquoi je veux faire cela? Je ne suis pas la création d'un site web mais une application web. Certains champs sont en lecture seule dans ce cas, ils look modifiable, mais si vous appuyez sur la touche retour arrière vous quittez la page. Le ratio de retour arrière presses de l'intention de revenir vs retour arrière presses à essayer d'effacer quelque chose qui est probablement beaucoup moins que 1 / 1000.
- Erik, champs en lecture seule ne faut pas regarder modifiable - pourquoi ne pas utiliser un peu de jQuery pour re-style de champs en lecture seule?
- Pour utiliser le même argument que les autres gens: C'est la norme, donc ça devrait être fait. Pour utiliser un argument réel: Oui, ce serait probablement une bonne idée, mais j'ai encore envie de prévenir les accidents.
- La question est de savoir comment le faire, pas votre avis sur si c'est une bonne idée ou pas. Sans connaître les détails du projet, vos opinions sont vides de sens. Mon client a expressément demandé à ce comportement pour un de mes projets et une vraie réponse plutôt que "Pourquoi voudriez-vous jamais eu envie de le faire?" serait utile.
- C'est un long-terme de "réparer", mais vous pouvez jeter votre soutien derrière le Chrome bug pour modifier ce comportement dans webkit: code.google.com/p/chromium/issues/detail?id=144832
- Je suis à l'aide de alt+gauche comme un bouton de retour, donc je suis prêt pour la désactivation de la touche retour arrière comme un bouton de retour. Hélas, IMDB a détourné les touches fléchées donc, je dois utiliser la touche retour arrière là.
- Google a inclus cette stupide-cul de mappage de touches de Chrome, mais ils ont également désactivé la cartographie dans leur page de résultats de recherche, faire de retour arrière agir en tant que la touche retour arrière devrait même lorsque la requête champ de texte n'est pas centré. Même les entreprises qui font les navigateurs n'aime pas cette clé de liaison.
- Les réponses à cette question ne sont pas assez bonnes. Ils sont trop complexes, pourrait ne pas attraper tous les cas d'accidents de navigation, et peut désactiver la normale "retour arrière" de la fonction dans des champs de saisie. Idéalement, les entreprises qui réalisent les navigateurs devraient désactiver cet os à tête de clé de liaison par défaut. Jusqu'à ce qui pourrait arriver, je vous suggère de simplement confirmer la navigation si tout le texte a été saisi dans les champs de formulaire. La deuxième réponse ici semble bon: stackoverflow.com/questions/5102602/...
- J'ai créé un projet MNP avec une version propre de la actuellement accepté de répondre: github.com/slorber/backspace-disabler
- Google a l'intention de supprimer le retour arrière de navigation le 26-juillet-2016. Il est actuellement disponible en Chrome 52 (bêta canal).
- Peut-être que les navigateurs peuvent aussi carte
delete
pour avancer d'une page? - Simple mais élégante solution qui peut ou peut ne pas fonctionner pour vous.. onkeydown="alert('Champ en Lecture Seule!'); return false;" ou onkeydown="return false;"
- Ce qui me dérange le plus dans tout ça, c'est que Breton commentaire a le plus de likes. Évidemment, il y a beaucoup de "développeurs de logiciels" qui sont trop fermé d'esprit pour voir toutes les raisons pour lesquelles vous pourriez avoir besoin de la touche retour arrière de navigation désactivé. Pour ceux qui ne sont pas à l'esprit fermé, je peux peut-être donner une idée: si l'utilisateur tape un grand nombre de données sur la page, ou ils sinon la page de telle sorte qu'une de navigation de changement serait de perdre leur travail, un simple, stupide retour arrière de navigation "mésaventure" par l'utilisateur peut être extrêmement frustrant perte de temps et d'efforts.
- Permettez-moi de vous rappeler à tous qu'il est de notre TRAVAIL pour faire de notre logiciel aussi convivial que possible. 90 logiciels de qualité juste ne sera pas coupé plus. Et si vous ne pouvez pas donner un sacrément si votre logiciel est top-notch ou si vos utilisateurs sont contenu, vous devez quitter et de trouver un autre emploi. Tous nous faire une faveur, de développeur et de l'utilisateur final comme.
Vous devez vous connecter pour publier un commentaire.
Ce code résout le problème, au moins dans IE et Firefox (ne l'ai pas testé les autres, mais je lui donne une chance raisonnable de travail si le problème existe même dans les autres navigateurs).
d.type.toUpperCase() === 'PASSWORD'
ainsi. Sinon regarde bienif( $(d).is( ":input" ) )...
$('.ui-dialog').length != 0
avant de bloquer le comportement par défaut. Seulement besoin de le faire lorsqu'une boîte de dialogue est ouverte.if( $(d).is( ":input" ) )
ne fonctionne pas, parce que si l'utilisateur sélectionne une zone de saisie, puis appuyez sur retour arrière les comportements indésirables se produit encore.contentEditable
attribut a été normalisé par le WHATWG et doit être pris en compte.d.isContentEditable
ici.if ( $(d).is(":text") || $(d).is(":password") || $(d).is(":file") || $(d).is("textarea") ) {
Mais il ne fonctionne pas pour html5 nouveaux éléments modifiables, et je ne comprends pas Chris Nash commentaire...unbind
etbind
appels afin de ne pas effacer des choses qui, vivent déjà surkeydown
n'importe où dans le document. ;^)Ce code fonctionne sur tous les navigateurs et avale la touche retour arrière lorsqu'il n'est pas sur un élément de formulaire, ou si l'élément de formulaire est désactivé|readOnly. Il est également efficace, ce qui est important quand il est en cours d'exécution sur chaque clé tapé dans l'.
if(!rx.test(e.target.tagName) || $(e.target).is(':checkbox') || $(e.target).is(':radio') || $(e.target).is(':submit') || e.target.disabled || e.target.readOnly )
contentEditable
..is(':checkbox,:radio,:submit')
Les autres réponses ici ont établi que cela ne peut se faire sans une liste blanche des éléments qui la touche retour arrière est autorisé. Cette solution n'est pas idéale, car la liste blanche n'est pas aussi simple que simplement ces zones de texte et texte/mot de passe intrants, mais à plusieurs reprises jugé incomplet et qui ont besoin d'être mis à jour.
Toutefois, étant donné que le but de la suppression de la fonctionnalité retour arrière est simplement pour empêcher les utilisateurs de perdre accidentellement des données, la beforeunload solution est bonne parce que le modal popup est surprenant--modal popups sont mauvais quand ils sont déclenchées dans le cadre d'un flux de travail standard, car l'utilisateur s'habitue à les rejeter sans les lire, et qu'ils sont ennuyeux. Dans ce cas, le modal popup doit apparaître uniquement comme une alternative à une rare et surprenant d'action, et est donc acceptable.
Le problème est que onbeforeunload modal ne doit pas pop up à chaque fois que l'utilisateur quitte la page (comme lorsque vous cliquez sur un lien ou l'envoi d'un formulaire), et nous ne voulons pas commencer à la liste blanche ou liste noire spécifiques onbeforeunload conditions.
La combinaison idéale de compromis pour une solution généralisée est comme suit: garder une trace de savoir si le retour arrière est enfoncé, et ne s'ouvrent que la onbeforeunload modale si elle est. En d'autres termes:
Cela a été testé pour fonctionner dans IE7+, FireFox, Chrome, Safari et Opera. Il suffit de déposer cette fonction dans votre global.js et de l'appeler à partir de n'importe quelle page où vous ne voulez pas que les utilisateurs de perdre accidentellement leurs données.
Noter qu'un onbeforeunload modal ne peut être déclenchée qu'une seule fois, donc si l'utilisateur appuie sur la touche retour arrière encore une fois, le modal ne se déclenche pas à nouveau.
Noter que ce ne sera pas de déclenchement sur hashchange événements, cependant, dans ce contexte, vous pouvez utiliser d'autres techniques pour empêcher des utilisateurs de perdre accidentellement leurs données.
Un plus élégant/concis solution:
Modification de erikkallen, en Réponse à l'adresse des différents types d'entrée
J'ai trouvé que l'esprit d'entreprise l'utilisateur peut appuyer sur la touche retour arrière sur une case à cocher ou un bouton radio dans une vaine tentative de le vider et à la place ils allaient revenir en arrière et de perdre toutes leurs données.
Ce changement devrait s'occuper de cette question.
Nouvelle Édition à l'adresse de contenu modifiable divs
Exemple
Pour tester faire 2 fichiers.
starthere.htm - ouvrir cette première de sorte que vous avez un endroit où aller retour à
test.htm - Cela permettra de naviguer vers l'arrière lorsque la touche retour arrière est enfoncé alors que la case à cocher ou soumettre a le focus (réalisé par tabulation). Remplacer avec mon code à corriger.
Sur la base des commentaires il semble que vous voulez arrêter de la perte de l'information dans les formes, si elles appuyez sur retour arrière pour supprimer, mais le champ n'est pas centrée.
Dans ce cas, vous voulez regarder la onunload gestionnaire d'événement. Un Débordement de pile utilise - si vous essayez de quitter une page lorsque vous avez commencé à écrire une réponse, il affiche un message d'alerte.
Arrêt de la navigation de ce code fonctionne!
Mais pour ne pas restreindre les champs de texte mais d'autres
Pour l'empêcher de domaine spécifique simplement utiliser
Se référant à celle-ci!
Prévenir le retour arrière de la navigation de retour avec jQuery (Comme Google page d'Accueil)
La plupart des réponses sont en jquery. Vous pouvez faire cela parfaitement en pur Javascript, simple et pas de bibliothèque nécessaires. Cette article est un bon point de départ pour moi, mais depuis keyIdentifier est obsolète, je voulais que ce code pour être plus sûr, j'ai donc ajouté ||e.keyCode==8 de l'instruction if. En outre, le code ne fonctionnait pas bien sur Firefox, j'ai donc ajouté return false; et maintenant il fonctionne parfaitement bien. Ici, il est:
Ce code fonctionne très bien parce que,
Ne sais pas pourquoi on n'a pas répondu à cette - semble parfaitement raisonnable technique de se poser la question de savoir si c'est possible.
Non, je ne pense pas qu'il y a une manière de croix-navigateur pour désactiver la touche retour arrière. Je sais que c'est pas activée par défaut dans FF ces jours si.
Combinant les solutions données par "thetoolman" && "Biff MaGriff"
code suivant semble fonctionner correctement dans IE 8/Mozilla/Chrome
Cette solution est similaire à d'autres qui ont été posté, mais il utilise une simple liste blanche, ce qui le rend facilement personnalisable pour permettre le retour arrière dans les éléments précisés, juste en mettant le sélecteur dans le .est() fonction.
- Je utiliser ce formulaire pour empêcher le retour arrière sur les pages de navigation de retour:
D'élaborer un peu sur @erikkallen de excellente réponse, voici une fonction qui permet à tous les clavier type d'entrée, y compris ceux qui ont été introduits en HTML5:
JavaScript - jQuery façon:
Javascript - le moyen natif, qui fonctionne pour moi:
J'ai eu un moment difficile de trouver un non-JQUERY réponse. Grâce à Stas pour me mettre sur la piste.
Chrome: Si vous n'avez pas besoin de la croix-prise en charge du navigateur, vous pouvez simplement utiliser une liste noire, plutôt que d'une liste blanche. Cette pure JS version fonctionne dans Chrome, mais pas sous IE. Pas sûr que sur FF.
En Chrome (ver. 36, pour la mi-2014), touches pas sur une entrée ou contenteditable élément semble être la cible de
<BODY>
. Cela rend possible l'utilisation d'une liste noire, que je préfère à la liste blanche. IE utilise la dernière sur la cible de sorte qu'il pourrait être un div ou autre chose. Qui rend inutiles dans IE.De la croix-Navigateur: Pour javascript, j'ai trouvé Stas réponse pour être le meilleur. En ajoutant une condition de vérifier pour contenteditable fait le travail pour moi*:
*Notez que S [edit: et Spartan/TechPreview] ont une "fonction" qui permet de tableau-les éléments liés à la non modifiable. Si vous cliquez sur l'un de ceux-ci et appuyez sur la touche retour arrière, il VA revenir. Si vous n'avez pas modifiable
<td>
s, ce n'est pas un problème.J'ai eu quelques problèmes avec la solution retenue et la Select2.js plugin; je n'étais pas en mesure de supprimer des caractères dans la zone modifiable comme la suppression de l'action a été empêché. C'était ma solution:
Select2 crée un Span avec un attribut de "contentEditable", qui est définie sur true pour le combo en elle. J'ai ajouté le code pour tenir compte de la portée tagName et l'attribut différent. Cela a résolu tous mes problèmes.
Edit: Si vous n'êtes pas à l'aide de la Select2 combobox plugin pour jquery, alors cette solution peut ne pas être nécessaire par vous, et la solution retenue pourrait être mieux.
Ce code résout le problème dans tous les navigateurs:
DIV
ouTD
.Façon la plus simple pour éviter de navigation sur la touche de retour arrière
À l'aide de Dojo toolkit 1.7, cela fonctionne sous IE 8:
Avez-vous essayé la solution très simple de simplement ajouter l'attribut suivant à votre lecture seule zone de texte:
onkeydown="return false;"
Cela permet de garder le navigateur de rentrer dans l'histoire lorsque la touche retour arrière est enfoncé dans un champ de texte en lecture seule. Peut-être que je suis absent de votre véritable intention, mais il semble que ce serait la solution la plus simple à votre problème.
Beaucoup plus propre solution -
Alternativement, vous pouvez uniquement vérifier si
Pure version javascript, qui fonctionne dans tous les navigateurs:
Bien sûr, vous pouvez utiliser le bouton "INPUT, TEXTAREA" et l'utilisation "if (!regex.test(éléments))" puis. Le premier a bien fonctionné pour moi.
Performance?
J'étais inquiet au sujet de la performance et a fait un violon: http://jsfiddle.net/felvhage/k2rT6/9/embedded/result/
J'ai analysé les méthodes les plus prometteuses j'ai trouvé dans ce thread. Il s'avère, ils ont tous été très rapide et le plus probablement de ne pas poser un problème en termes de "lenteur" lors de la saisie.
La Méthode la plus lente j'ai regardé était d'environ 125 ms pour 10.000 Appels dans IE8. Qui est 0.0125 ms par accident vasculaire cérébral.
J'ai trouvé les méthodes posté par Codenepal et Robin Maben à être le plus rapide ~ 0.001 ms (IE8) mais méfiez-vous des différentes sémantiques.
C'est peut-être un soulagement pour quelqu'un de la présentation de ce type de fonctionnalité à son code.
Modifié erikkallen réponse:
Cette solution a très bien fonctionné lors des tests.
J'ai fait ajouter un peu de code pour gérer certains champs de saisie sont pas marqués avec entrée, et de les intégrer dans un Oracle PL/SQL d'une application qui génère un formulaire de saisie pour mon travail.
Mon "grain de sel":
J'ai créé un projet MNP avec une version propre de la actuellement acceptées (de erikkallen)
https://github.com/slorber/backspace-disabler
Il utilise essentiellement les mêmes principes, mais:
Voici ma réécriture de haut-voté réponse. J'ai essayé de vérifier l'élément.la valeur!==non défini (car certains éléments comme peut n'avoir aucun attribut html, mais peut avoir une valeur javascript propriété quelque part sur la chaîne de prototype), cependant cela ne fonctionne pas très bien et a eu beaucoup de cas de bord. Il ne semble pas être une bonne façon d'assurer la pérennité de cela, donc une liste blanche semble la meilleure option.
Il enregistre l'élément à la fin de l'événement phase de propagation, donc si vous voulez gérer le retour arrière en aucune façon personnalisée, vous pouvez le faire dans d'autres gestionnaires.
Ce vérifie également instanceof HTMLTextAreElement car on pourrait en théorie avoir un composant web qui hérite de que.
Ce ne vérifie pas contentEditable (à combiner avec d'autres réponses).
https://jsfiddle.net/af2cfjc5/15/
Sitepoint: Désactiver le dos pour Javascript
event.stopPropagation()
etevent.preventDefault()
ne rien faire dans IE. J'ai dû envoyer retourevent.keyCode == 11
(j'ai juste pris quelque chose) au lieu de dire"if not = 8, run the event"
pour le faire fonctionner, cependant.event.returnValue = false
fonctionne également.Une autre méthode à l'aide de jquery
J'ai été en utilisant ce dans mon code pour un certain temps maintenant. J'écris des tests en ligne pour les étudiants et a couru dans le problème lorsque les étudiants ont été en appuyant sur la touche retour arrière lors de leur test et qu'il faudrait revenir à l'écran de connexion. Frustrant! Il fonctionne sur FF pour sûr.
A fonctionné pour moi
Pour tous ceux qui sont intéressés, j'ai mis en place un plugin jQuery qui intègre thetoolman's (plus @MaffooClock/@cdmckay commentaires) et @Vladimir Kornea's idées ci-dessus.
Utilisation:
Plugin:
Toutes les réponses apportées jusqu'à présent se concentrer sur le script de la correction dans la page web, mais si je veux simplement que la fonctionnalité pour moi-même, sans affecter les autres utilisateurs?
Dans ce cas, une solution pour le navigateur lui-même est à privilégier:
- Firefox sur Linux "mappage" le retour arrière comportement depuis 2006, il n'est donc pas affectées; (en tout cas, il a été tout simplement mis à défiler vers le haut avant)
- Chrome vient d'annoncer qu'il va faire la même chose à partir de maintenant; (http://forums.theregister.co.uk/forum/1/2016/05/20/chrome_deletes_backspace/)
- Firefox sur Windows peut être configuré pour ignorer la touche retour arrière en allant dans about:config et changer le backspace_action réglage à 2; (http://kb.mozillazine.org/Browser.backspace_action)
- Safari ?!