Em sua infinita sabedoria, a Apple criou sua própria maneira de emular eventos hover em dispositivos de toque. Se o iOS Safari determinar que passar o mouse sobre um elemento fará com que um elemento filho seja mostrado, o navegador acionará os :hoverestilos CSS do pai no primeiro toque e cancelará quaisquer eventos de clique que possam ser causados por elementos filho. Isso faz com que o elemento filho apareça.
Infelizmente, esse estado de foco não padrão é redefinido apenas quando outro “elemento clicável” é clicado, o que é um problema se o usuário segue um link filho para outra página enquanto o estado de pseudo foco ainda está em vigor.
Quando o botão “voltar” do navegador é usado, a página anterior é restaurada do cache (“bfcache” para ser mais preciso) exatamente como estava quando a página foi encerrada. Nesse ponto, se a página restaurada contiver um elemento com o estado de foco emulado ainda em vigor, nada poderá ser feito para redefini-lo. Mesmo se o elemento filho ainda visível do elemento “pairado” estiver oculto programaticamente ou se outro elemento clicável receber o foco, os cliques subsequentes no elemento pai se comportarão como se o comportamento do “primeiro toque” já tivesse ocorrido. Isso pode ser problemático.
Por exemplo, se essa situação foi acionada para um item de nível superior de um menu no estilo Suckerfish, a página restaurada em cache mostrará o submenu ainda aberto. Se você conseguir ocultar o submenu clicando em outro lugar, o item pai não acionará mais o efeito de emulação de foco e seu link será seguido imediatamente. Isso torna o submenu associado inacessível. Só descobri uma maneira de contornar isso: uma atualização adequada da página. As desvantagens de sempre forçar uma atualização de página são significativas, portanto, esteja avisado.
O código a seguir detecta o iOS Safari e, em seguida, detecta se a página foi carregada do bgcache e, em caso afirmativo, força uma atualização da página. No entanto, você perde completamente os benefícios do bgcache. Usar o botão Voltar do iOS Safari forçará uma atualização (muito mais lenta). Pior ainda: também ocorrerá uma atualização ao voltar de outra guia ou aplicativo, ou até mesmo ao ligar a tela novamente depois que ela entrar no modo de espera. Qualquer trabalho inacabado na página seria perdido.
Com os terríveis avisos fora do caminho, aqui está o código JavaScript que força uma atualização de página em vez de uma restauração de bfcache (usa o anexo de evento do jQuery):
if (/iPhone|iPad|iPod/i.test(navigator.userAgent)) {
$(window).on('pageshow', function(e) {
if (e.originalEvent.persisted) {
window.location.reload();
}
});
}