Ajax, botão voltar e atualizações DOM

Se o javascript modificar o DOM na página A, o usuário navegará até a página B e depois voltará ao botão voltar para a página A. Todas as modificações no DOM da página A são perdidas e o usuário recebe a versão originalmente recuperada do servidor.

Funciona dessa forma em stackoverflow, reddit e muitos outros sites populares. (tente adicionar comentário de teste a esta pergunta, navegue para a página diferente e pressione o botão Voltar para voltar – seu comentário será “perdido”)

Isso faz sentido, mas alguns sites (apple.com, basecamphq.com etc) estão de alguma forma forçando o navegador a servir ao usuário o estado mais recente da página. (vá para http://www.apple.com/ca/search/?q=ipod , clique em “Fazer download do link na parte superior e, em seguida, clique no botão voltar – todas as atualizações do DOM serão preservadas)

De onde vem a inconsistência?

Uma resposta: entre outras coisas, os events de descarregamento fazem com que o cache de back / forward seja invalidado .

Alguns navegadores armazenam o estado atual de toda a página da Web no chamado “bfcache” ou “cache de páginas”. Isso permite que eles reproduzam a página muito rapidamente ao navegar pelos botões voltar e avançar e preservar o estado do DOM e todas as variables ​​JavaScript. No entanto, quando uma página contém events onunload, esses events poderiam potencialmente colocar a página em um estado não-funcional e, portanto, a página não é armazenada no bfcache e deve ser recarregada (mas pode ser carregada a partir do cache padrão) e renderizado do zero, incluindo a execução de todos os manipuladores onload. Ao retornar a uma página através do bfcache, o DOM é mantido em seu estado anterior, sem a necessidade de triggersr manipuladores de carga (porque a página já está carregada).

Observe que o comportamento do bfcache é diferente do cache padrão do navegador em relação ao Cache-Control e outros headers HTTP. Em muitos casos, os navegadores armazenam em cache uma página no bfcache, mesmo que, de outra forma, ela não fosse armazenada no cache padrão.

O jQuery anexa automaticamente um evento de descarregamento à janela, portanto, infelizmente, o uso do jQuery desqualifica a sua página de ser armazenada no bfcache para preservação do DOM e back / forward rápido . [Atualização: isso foi corrigido no jQuery 1.4, de modo que se aplica apenas ao IE]

  • Informações sobre o Firefox bfcache
  • Informações sobre o cache de páginas do Safari e possíveis mudanças futuras na forma como os events de descarregamento funcionam
  • Opera usa navegação rápida no histórico
  • O Chrome não tem um cache de páginas ( [1] , [2] )
  • Páginas para jogar com manipulações DOM e o bfcache:
    • Esta página será armazenada no cache regular
    • Esta página não será, mas ainda será fcached

Eu tenho tentado fazer com que o Chrome se comporte como o Safari, e a única maneira que descobri é que ele funciona para definir o Cache-control: no-store nos headers. Isso força o navegador a recuperar a página do servidor quando o usuário pressiona o botão Voltar. Não é o ideal, mas é melhor do que mostrar uma página desatualizada.

O Facebook lembra o estado da página modificando o identificador de hash na URL para solicitações ajax. Essas alterações são registradas no histórico do navegador, portanto, quando o usuário clica no botão Voltar, o hash muda para o que era antes. Então, está implícito que você precisará de algum Javascript para monitorar o identificador e reagir quando for alterado pelo navegador. Andreas Blixt tem um script de monitoramento de hash disponível .

Isso não tem nada a ver com o símbolo de hash (#).

Se você verificasse os headers HTTP da Apple, seria simplesmente armazenar em cache a página.

Usar o identificador de hash / fragment de URL é uma maneira bastante comum de ligar / lembrar o estado em um aplicativo da Web que depende de atualizações de Ajax e DOM.

Confira o projeto Really Simple History para algumas idéias. É possível monitorar a URL para alterações no hash e o rsh faz isso, levando em conta as diferenças do navegador.

Para qualquer um correndo em problemas com Rails e isso – seu problema não é bfcache (eu pensei que fosse) – é a jóia de turbolinks . Aqui está como removê-lo.

Espero que isso te poupe um pouco e jogue sua cabeça contra a parede.

O que você está procurando é para algum tipo de gerenciamento de hash de URL. O # na URL é apenas para o lado do cliente.

Quando você altera o estado do back com JS, atualiza os dados no # da URL.

Além disso, você adiciona algum tipo de pesquisa que monitora se o hash foi alterado e carrega o estado da página com base nos novos dados no hash.

Dê uma olhada neste:

http://ajaxpatterns.org/Unique_URLs