Ajax, bouton de retour et mises à jour DOM

Si javascript modifie le DOM dans la page A, l'utilisateur accède à la page B, puis clique sur le bouton de retour pour revenir à la page A. Toutes les modifications apportées au DOM de la page A sont perdues et l'utilisateur reçoit la version qui a été récupérée à l'origine sur le serveur.

Cela fonctionne de cette façon sur stackoverflow, reddit et de nombreux autres sites Web populaires. (essayez d'ajouter un commentaire de test à cette question, puis accédez à une page différente et appuyez sur le bouton retour pour revenir - votre commentaire sera "parti")

Cela a du sens, mais certains sites Web (apple.com, basecamphq.com, etc.) obligent en quelque sorte le navigateur à fournir à l'utilisateur le dernier état de la page. (allez sur http://www.apple.com/ca/search/?q=ipod , cliquez sur le lien de téléchargement en haut, puis cliquez sur le bouton retour - toutes les mises à jour DOM seront conservées)

d'où vient l'incohérence?

Une réponse: entre autres, les événements de déchargement entraînent l'invalidation du cache arrière / avant .

Certains navigateurs stockent l'état actuel de la page Web entière dans ce que l'on appelle «bfcache» ou «cache de page». Cela leur permet de restituer la page très rapidement lors de la navigation via les boutons Précédent et Suivant, et préserve l'état du DOM et de toutes les variables JavaScript. Cependant, lorsqu'une page contient des événements onunload, ces événements peuvent potentiellement mettre la page dans un état non fonctionnel, et ainsi la page n'est pas stockée dans le bfcache et doit être rechargée (mais peut être chargée à partir du cache standard) et re- rendu à partir de zéro, y compris l'exécution de tous les gestionnaires onload. Lors du retour sur une page via le bfcache, le DOM est conservé dans son état précédent, sans avoir besoin de déclencher des gestionnaires onload (car la page est déjà chargée).

Notez que le comportement du bfcache est différent du cache standard du navigateur en ce qui concerne Cache-Control et d'autres en-têtes HTTP. Dans de nombreux cas, les navigateurs mettront en cache une page dans le bfcache même s'il ne la stockerait pas autrement dans le cache standard.

jQuery attache automatiquement un événement de déchargement à la fenêtre, donc malheureusement, l'utilisation de jQuery disqualifiera votre page d'être stockée dans le bfcache pour la préservation du DOM et un retour / avance rapide. [Mise à jour: cela a été corrigé dans jQuery 1.4 afin qu'il ne s'applique qu'à IE]

• Informations sur Firefox bfcache
• Informations sur le cache de page Safari et les modifications futures possibles du fonctionnement des événements de déchargement
• Opera utilise une navigation rapide dans l'historique
• Chrome n'a pas de cache de page ( [1] , [2] )
• Pages pour jouer avec les manipulations DOM et le bfcache:
  • Cette page sera stockée dans le cache normal
  • Cette page ne sera pas, mais sera toujours bfcached

J'ai essayé de faire en sorte que Chrome se comporte comme Safari, et le seul moyen que j'ai trouvé que cela fonctionne est de définir les Cache-control: no-storeen-têtes. Cela oblige le navigateur à récupérer la page à partir du serveur lorsque l'utilisateur appuie sur le bouton Précédent. Pas idéal, mais mieux que de voir une page obsolète.

Facebook se souvient de l'état de la page en modifiant l'identifiant de hachage dans l'URL pour les requêtes ajax. Ces modifications sont enregistrées dans l'historique du navigateur, de sorte que lorsque l'utilisateur clique sur le bouton Précédent, le hachage change à ce qu'il était auparavant. Il est donc sous-entendu que vous aurez besoin de Javascript pour surveiller l'identifiant has et réagir lorsqu'il est modifié par le navigateur. Andreas Blixt a un script de surveillance de hachage disponible .

Cela n'a rien à voir avec le symbole dièse (#).

Si vous voulez vérifier les en-têtes HTTP d'Apple, c'est simplement la mise en cache de la page.

L'utilisation de l'identifiant de hachage / fragment d'URL est un moyen assez courant de hooker / de mémoriser l'état dans une application Web qui repose sur les mises à jour Ajax et DOM.

Consultez le projet d' histoire vraiment simple pour quelques idées. Il est possible de surveiller l'URL pour les modifications apportées au hachage, et rsh le fait, en tenant compte des différences de navigateur.

Pour quiconque a des problèmes avec Railset ceci - votre problème n'est pas bfcache (je pensais que c'était le cas) - c'est le turbolinksjoyau. Voici comment le supprimer.

J'espère que cela vous fera gagner du temps et vous cognera la tête contre le mur.

Ce que vous recherchez, c'est un type de gestion de hachage d'URL. Le # dans l'url est pour le côté client uniquement.

Lorsque vous modifiez l'état du dos avec JS, vous mettez à jour les données dans le # de l'url.

Vous ajoutez également un type d'interrogation qui surveille si le hachage a changé et charge l'état de la page en fonction des nouvelles données du hachage.

Regarde ça:

http://ajaxpatterns.org/Unique_URLs