tl;dr – Safari en iOS 5 es el almacenamiento en caché por lo que es difícil de romper mi sitio.

Estoy luchando con la forma en que el navegador Safari en iOS 5 se ocupa de atrás adelante caché, lo que ellos llaman «la Caché de la Página». La forma en que se describe aquí explica el comportamiento muy bien.

Sencillamente, el Caché de la Página hace tan al salir de una página que nos «pausa» y cuando venga de vuelta, presione el botón «jugar».

Esto está causando problemas a lo largo de mi sitio. Cuando se utiliza el botón atrás, la mayoría de los navegadores mostrará la página en el estado en el que estaba cargado. No Safari en iOS 5, se muestra la página tal y como la última que queda. Un ejemplo sencillo sería la inhabilitación de un botón de enviar. Si puedo usar Javascript para deshabilitar el botón de enviar, a continuación, enviar un formulario, al pulsar de nuevo el botón de enviar todavía estará deshabilitado. Este ha sido un problema en otros navegadores, incluyendo la versión de escritorio de Safari, pero es resuelto mediante la configuración del controlador de eventos onload a un espacio en blanco de la función. Creo que esto le dice al navegador para invalidar la caché porque algo importante que podría haber ocurrido en esa función. Este hack no parece funcionar para Safari en iOS 5.

A continuación es la cuestión se reduce a lo esencial. Cuando se carga test.html verá el texto «Texto Original». Cuando usted haga clic en el enlace, el texto cambiará a «Cambiar el texto de reenvío de la página siguiente», luego en 3 segundos, se te enviará a test2.html. Todo es bueno hasta este punto en todos los navegadores. En todos los demás navegadores, cuando usted haga clic en el botón atrás, el texto que se ve es «Texto Original», pero en Safari para iOS 5 va a ver «el texto Modificado de reenvío de la página siguiente».

Cualquier sugerencia sobre cómo lidiar con esto?

Este es un ejemplo sencillo

test.html

<script>
function changeText() {
    el = document.getElementById("text");
    el.innerHTML = "Changed text - forwarding to next page";
    setTimeout("forward()",3000);       
}
function forward() {
    document.location.href = "test2.html";
}
</script>
<div id="text">Original Text</div>
<a href="Javascript:changeText()">Click Here</a>
<script>
window.onunload = function(){};
</script>

test2.html

<div>Click back button</div>

Este es un segundo ejemplo de uso de una forma de post. Este es un ejemplo sencillo de cómo mi aplicación está funcionando. Cuando vaya de nuevo a la formtest2.asp, usted debe ver el formulario expuesto valor y el div texto debe ser original.

formtest.asp

<form method="post" action="formtest2.asp">
    Test: <input type="text" name="test"/>
    <input type="submit" value="Submit"/>
</form>

formtest2.asp

<script>
function changeText() {
    el = document.getElementById("text");
    el.innerHTML = "Changed text - forwarding to next page";
    setTimeout("forward()",3000);       
}
function forward() {
    document.location.href = "test2.html";
}
</script>

<%
Dim test
test = Request("test")
Response.Write("Test value: " & test & "<br />")
%>

<div id="text">Original Text</div>
<a href="Javascript:changeText()">Click Here</a>
<script>
window.onunload = function(){};
</script>

test2.html

<div>Click back button</div>
  • Sólo un poco más de información sobre esto. Parece como si todos los navegadores que he probado (Firefox, IE, Safari Escritorio) disparo pagehide, y descargar, en ese orden. Safari en iOS 5 incendios pagehide.
  • Al abrir una nueva pestaña, el evento unload no es despedido, sólo pagehide. Al abrir una nueva pestaña, usted tendría que esperar a ser capaz de navegar de vuelta a un viejo ficha y ver la página justo como la había dejado. El problema es que al navegar de una página a la siguiente, en la misma pestaña/ventana, el evento de descarga debería ser despedido por el w3c, pero no lo es. w3.org/TR/DOM-Level-2-Events/events.html. «El evento unload ocurre cuando la implementación DOM elimina un documento desde una ventana o marco. Este evento es válido para el CUERPO y para el conjunto de MARCOS de elementos.»
  • Cualquier solución utilizando la ubicación.reload() falla porque para esta función, Safari en ios 5 solo hacer un GET, no es un POST como todos los demás navegadores.
  • Hemos encontrado una solución que funciona para nosotros. Estamos ejecutando nuestra aplicación en HTTPS que evita la parte de atrás hacia adelante de la caché.
  • Nada que añadir, excepto que este es un ejemplo perfecto de lo que una cuestión debería ser en mi humilde opinión… +1!
  • de Safari en el Ipad, ¿qué acerca de stackoverflow.com/questions/24524248/…

InformationsquelleAutor Clarke | 2011-11-03

4 Comentarios

  1. 26

    Yo también estaba buscando una respuesta a la misma cuestión. Volviendo atrás en el iOS 5 no se ejecuta todo el código javascript y sólo deja la página en el estado anterior era cuando la izquierda o a la redirigido.

    Tratando el raro «onunload» hack que se encuentra en «Hay un cross-browser evento onload al hacer clic en el botón atrás?» sólo trabajó para iOS 4, no iOS 5, que no llame a la cita, como se esperaba. Nickolay señaló nuevas funciones en la web-kit llamado «pageshow» y «pagehide», que son mucho más fiable que la de Giuseppe ejemplo.

    1. Usted necesita el hack de este artículo: «Hay un cross-browser evento onload al hacer clic en el botón atrás?» para que esto funcione en iOS 4.
    2. Utilizar esta secuencia de comandos que utiliza el nuevo evento de forma segura de comprobar si la página se carga desde la memoria caché y forzar la recarga (evitando las Url de los cheques y los locales de almacenamiento y también incluyen el ipod) para iOS 5:

      <body onunload="">
      ...
      <script type="text/javascript">
      if ((/iphone|ipod|ipad.*os 5/gi).test(navigator.appVersion)) {
        window.onpageshow = function(evt) {
          //If persisted then it is in the page cache, force a reload of the page.
          if (evt.persisted) {
            document.body.style.display = "none";
            location.reload();
          }
        };
      }
      </script>
    • En la final, esta solución es la misma que el resto en que hacer una recarga no soluciona mi problema. Desde abajo, «Esta solución funciona bien para contenido dinámico a las páginas, pero se descompone cuando se navega a una página que está esperando el envío de un formulario. La ubicación.reload() sólo las cargas que URI y no registra la forma original de los valores.»
    • Usted necesita escribir el POST parámetros que desea re-POST para el marcado con código del lado del servidor (igual que la forma en que está escrito el «test» de la variable). Inyectar oculta los elementos de entrada bajo el elemento de formulario para todas las variables que desea PUBLICAR de nuevo. A continuación, utilizando la misma base de código anterior, en lugar de hacer una recarga, acaba de hacer un formulario de envío.
    • Que parecía una buena solución, pero en la realidad no lo es. Que evento a veces dispara a veces no. Aún no puedo explicar cómo repetir que el problema, intente abrir la página 1, página 2, a continuación, haga clic en atrás, se dispara el evento, a continuación, repita un par de veces.
  2. 1

    Estoy con el mismo problema.

    En iOS4, cuando se navega homepage.html a 2.html y luego de vuelta a homepage.html el js no ser llamado. cuando usted vaya homepage.html a 2.html desde 2.html usted va a continuar 3.html y luego de nuevo a partir del 3 a 2 a la página de inicio, el JS será llamado! Sí, Es terrible!

    Pero en iOS5 MobileSafari, siempre no se puede llamar 🙁 tal vez esto es un error de caché en iOS5. He probado en iOS 5.0.0 y 5.0.1, tiene el mismo resultado.

    Pero a la hora de implementar el evento onUnload en body elemento, se puede solucionar el backforward problema en la anterior MobileSafari.
    Simplemente he cambiado el <body> a <body onUnload=""> en homepage.html luego a partir de página de inicio para 2.html, cuando iba de regreso a la página de inicio, el código javascript en la página principal se llama. Funciona en FF, Escritorio de Safari Mobile Safari(iOS4)

    Así que, ¿cómo podemos hacer en iOS5? Por desgracia no he encontrado una solución. Pero mi aplicación web se ejecuta en un cliente nativo, he arreglado esto mediante la adición de un reload() llamada de los nativos:

     si (isOS5_) 
    { 
    [webView stringByEvaluatingJavaScriptFromstring:@"ubicación.reload();"]; 
    } 
    

    cuando webViewDidFinishLoad:

    • He intentado añadir una recarga de la página cuando se vuelve a él, pero esto causa problemas en las páginas que están esperando un post de formulario. La recarga simplemente carga el URI sin la publicación de los datos del formulario.
  3. 1

    en mi sitio móvil, he corregido el problema con este pequeño Código JS:

    if ((/iphone|ipad.*os 5/i).test(navigator.appVersion)) {
        window.onload=function () {
            localStorage.setItem("href",location.href);
        };
        window.onpopstate=function () {
            var a=localStorage.getItem("href"),
                b=location.href;
            if (b!==a&&b.indexOf((a+"#"))===-1) {
                document.body.style.display="none";
                location.reload();
            }
        };
    }

    Escenario:

    Clic en el enlace «Page2» de «Page1»: una Vez pulsado «Page1» se cierra,
    «Page2» se carga y dispara el onload y muchos otros eventos.

    [Página 1] -> haga clic en el enlace -> [Page2] -> onload -> onpopstate -> …

    A este punto, si usted haga clic en el botón atrás de su navegador, «Page2» se
    cerrado y «Page1» se carga y dispara el onload y muchos otros eventos.

    [Page2] -> haga clic en el botón atrás -> [Página 1] -> onload -> onpopstate -> …

    Clic en el botón atrás en IOS5 hace de cierre «Page1» y «Page2» aparece pero
    la página no se carga, el área de visualización de la escala se corrompe y el único evento
    es despedido de onpopstate.

    [Page2] -> haga clic en el botón atrás -> [Página 1] -> onpopstate.

    La Revisión:

    La revisión de las obras de los eventos onload, onpopstate y el objeto localStorage.

    onload es el primer evento gestionado por el script, y dentro de este se almacena el
    ubicación actual.href en localStorage.

    Si no hay ningún error, en onpopstate la ubicación actual.href y el href
    almacenado debe ser el mismo y la secuencia de comandos debe hacer nada.

    Utilizando Safari en IOS5 la página no se carga y el evento onload no es despedido, entonces
    ubicación.href y almacenado a href son diferentes en onpopstate evento.

    En este caso sólo ocultar la página actual (por otro bug en ventanilla relacionados con la
    este) y volver a cargar la página con el objeto de ubicación.

    • Gracias por el aporte, aunque no va a funcionar para mí. Desde que esto funciona para usted, usted lo desea, puede añadir el ipod a la instrucción if. Tenía que hacer esto porque un iPod Touch es lo que yo uso para pruebas y tuve que agregar para hacer que funcione. Esta solución funciona bien para contenido dinámico a las páginas, pero se descompone cuando se navega a una página que está esperando el envío de un formulario. La ubicación.reload() sólo las cargas que URI y no registra la forma original de los valores. Aquí es donde mi ejemplo de html anterior es incompleta.
  4. 0

    Después de encontrar la manera de evitar que uno de los problema(s) que todos parecen tener en este, me dura me gustaría compartir 🙂

    Después de leer algunos temas relacionados sobre el tema, principalmente en stack overflow «más caliente de los sujetos», el manejo de la Página de «Caché» ( http://www.webkit.org/blog/427/webkit-page-cache-i-the-basics/ y http://www.webkit.org/blog/516/webkit-page-cache-ii-the-unload-event/ ), seleccionando la opción «descargar» del evento ( developer.apple.com/library/IOS/ipad/#documentation/AppleApplications/Reference/SafariWebContent/HandlingEvents/HandlingEvents.html ) /»pageshow» ¿ nohing tienen que lidiar con la breve página de «aparición» en su estado anterior ( no la página anterior estado INICIAL, pero sólo la página de la izquierda ), mientras que el usuario cambie de nuevo a la app /o desbloquear su dispositivo o regresa a la aplicación después de salir de ella.

    Parece (para mí,al menos) , que este «visible de la página glitch» fue resuelto cuando hice la actualización para IOS6 ,como 5 minutos atrás ;D

    Yo era capaz de usar mi webapp en mobile safari como normal, y después de añadirlo a la pantalla de inicio, el comportamiento en el caso de «aplicación de conmutación» o «reiniciar» ,con o sin borra la caché, es la misma que la de su primer inicio: usted verá una página en BLANCO y, a continuación, su contenido (que puede ser la página correspondiente a la dirección url que se guardan en la pantalla de inicio, o cualquier otro contenido cargado mediante localStorage, por ejemplo, [mi caso (..) ] ).

    Para los eventos en los que yo era capaz de atrapar, ni en IOS4 dispositivos IOS5 me las puedo arreglar para deshacerse de esa «visual persistencia glitch». Supongo que es debido a la forma «de Caché de la Página» funciona, pero ahora estoy corriendo IOS6 en el iPad, como el fallo no está más allí, supongo que el equipo del Safari debe haber mejorado la forma en que manejan la «pantalla de inicio» webapps (..)

Dejar respuesta

Please enter your comment!
Please enter your name here