modo - version escritorio safari ios 12

El encabezado fijo desapareció al desplazarse hacia abajo en la vista web en iOS 11

Question

Tengo una aplicación nativa de iOS con una vista web para mostrar contenido web. Tengo un encabezado fijo en mi aplicación con las siguientes propiedades:

#header {
height: 60px;
background-color: @mainColor;
color: #ffffff;
padding: 10px;
text-align: center;
position: fixed;
width: 100%;
z-index: 1;
}

Antes de actualizar a iOS 11, todo funcionó bien. Ahora cuando me desplazo hacia abajo / arriba, el encabezado desaparece durante el desplazamiento, y cuando termina el desplazamiento, el encabezado aparece nuevamente.

Esto también se puede reproducir en Xcode 8.

Answer 1

¿Intentó usar la position:sticky lugar de la position:fixed ?

En el pasado funciona muy bien en iOS. Tenga en cuenta que es la position:sticky regla de la regla repetida position:sticky que se definirá.

Entonces, la solución final en su caso debería ser:

#header {
height: 60px;
background-color: @mainColor;
color: #ffffff;
padding: 10px;
text-align: center;
position: -webkit-sticky;
position: sticky;
top: 0;
width: 100%;
z-index: 1;
}

Además, si necesita una compensación adicional desde la parte superior, puede ajustar la top:0; regla de cero a cualquier número en px.

Y una nota final más: que el elemento adhesivo no extraerá elemento del flujo de documentos y actuará como elemento de documento ordinario (como div con position:static o relative ), pero no como elemento de posición absoluta (en el caso de fixed o absolute ).

http://caniuse.com/#feat=css-sticky

Answer 2

El truco es forzar la aceleración de la GPU. Haga esto agregando translate3d al elemento #header .

transform: translate3d(0,0,0);

Si los elementos anidados dentro del elemento #header continúan desapareciendo, agregue translate3d a ellos también.

Answer 3

Es posible que ya haya visto esta publicación sobre algunos cambios en iOS 11 , pero si no, ¿se aplicaría a su situación?

Uno de los viewport-fit: contain/cover/auto opciones viewport-fit: contain/cover/auto ?

¿O cambiando tu código para usar un valor constant para el padding-top ?

Answer 4

He estado batallando contra este mismo problema yo mismo.

El problema (al menos como se manifiesta en la aplicación en la que estoy trabajando) solo parece suceder en pantallas que son una combinación de alto (en el sentido de que requieren una gran cantidad de desplazamiento) y bastante complejas.

Generalmente, al menos para mí, el problema solo parece manifestarse cuando se activa el desplazamiento de impulso.

Aunque hay una pantalla en particular, que contiene 15 filas de imágenes desplazables de izquierda a derecha, eso romperá la cabeza / pie de página sin importar cuán lento lo desplace.

En mi propia defensa ... no tuve absolutamente nada que ver con el diseño. :-)

De todos modos...

Después de mucho buscar en una experimentación, he logrado encontrar una "solución" de géneros.

Eso sí, no estoy diciendo que este sea el camino a seguir aquí. Pero tal vez alguien con más experiencia que yo en el espacio de la aplicación móvil, pueda tomar esta información y extrapolar algo menos apetecible.

La primera pieza se ve así:

html,
body {
position: fixed;
width: 100%;
height: 100%;
overflow: hidden;
-webkit-overflow-scrolling: auto;
}

Y luego para el contenedor que actúa como el cuerpo principal de su pantalla:

.main-content-area {
overflow-y: auto;
height: 100%;
}

Esto va a matar el impulso de desplazamiento para su aplicación. Lo cual no es genial, lo sé. Pero como resultado de restringir la capacidad del usuario para desplazarse muy rápido, la representación de la pantalla parece ser capaz de mantenerse al día y el problema desaparece.

Nuevamente, no estoy recomendando esto como una solución viable para la producción. Porque obviamente no es genial.

Estoy ofreciendo esto más como un posible trampolín para una solución real, con la esperanza de que ayude.

=== >>> ACTUALIZACIÓN:

Tengo una solución de trabajo. Pero, como han señalado otros antes que yo, tuve que evitar el uso del Posicionamiento Fijo.

En cambio, utilicé Posicionamiento absoluto para definir las secciones Encabezado, Pie de página y Contenido principal de la página. Luego, permitía desplazarse solo en la sección Contenido principal.

Si ayuda, tengo el POC que BitBucket disponible en BitBucket

Answer 5

La posición fija no funciona bien con iOS, pero utilicé la posición absoluta en mis aplicaciones de Córdoba, lo que nunca me causa ningún problema.

Answer 6

Solo estoy escribiendo un código, intente con uno por uno

• Prueba con abajo

  self.automaticallyAdjustsScrollViewInsets = false

• Prueba con abajo

  [self.webView.scrollView setContentInsetAdjustmentBehavior:UIScrollViewContentInsetAdjustmentNever];

• Pruebe con a continuación (cambie su código)

  header {
  height: 60px;
  background-color: @mainColor;
  color: #ffffff;
  padding: 10px;
  text-align: center;
  position: fixed;
  width: 100%;
  z-index: 1;
  transform: translateZ(0);
  -moz-transform: translatez(0);
  -ms-transform: translatez(0);
  -o-transform: translatez(0);
  -webkit-transform: translateZ(0);
  -webkit-font-smoothing: antialiased;
  }

  ¡Y algunos enlaces útiles pueden serle útiles!

• http://ayogo.com/blog/ios11-viewport/

• https://forums.developer.apple.com/thread/90472
• Cómo arreglar el elemento de entrada de iOS 11 en un error de modales fijo
• https://github.com/PierBover/ios-iframe-fix
• https://stanko.github.io/ios-safari-scoll-position-fixed/

De la nota oficial de Apple:

Importante:

A partir de iOS 8.0 y OS X 10.10, use WKWebView para agregar contenido web a su aplicación. No use UIWebView o WebView.

Entonces debería intentarlo una vez con WKWebView .

Answer 7

Tuve el mismo problema con ambas posiciones: fija y posición: adhesiva. La conversión de UIWebView a WKWebView lo solucionó por mí:

#import <WebKit/WebKit.h>
....
@property (weak, nonatomic) IBOutlet WKWebView *myWebView;

"A partir de iOS 8.0 y OS X 10.10, use WKWebView para agregar contenido web a su aplicación. No use UIWebView o WebView".

https://developer.apple.com/documentation/webkit/wkwebview

Answer 8

Tuve un problema similar con un proyecto de Cordova creado para iOS, que usa una vista web. Cordova utiliza el UIWebView de forma predeterminada como su motor de vista web y probé todas las soluciones posibles mencionadas en este hilo y muchas otras. Finalmente, nuestra única solución fue cambiar el motor de vista web de UIWebView a WKWebView ( https://developer.apple.com/documentation/webkit/wkwebview ). Con Cordova, presentar WKWebView es bastante sencillo con un complemento https://github.com/apache/cordova-plugin-wkwebview-engine

Después de presentar WKWebView y lidiar con algunos de los problemas que causa, ya no estamos experimentando el parpadeo o la desaparición de los elementos posicionados mientras se desplaza en iOS 11.

Answer 9

Tuvimos un problema similar y se solucionó con los siguientes 2 complementos

https://github.com/apache/cordova-plugin-wkwebview-engine https://github.com/TheMattRay/cordova-plugin-wkwebviewxhrfix

El primer complemento cambiará WebView predeterminado a WKWebView y el segundo complemento proporcionará solución para el problema CORS que vemos al usar WKWebView.

Answer 10

esto funciona para mí

position: sticky

Answer 11

position: fixed always has been a problem con iOS. Parece que en cada versión de iOS el problema persiste. Ahora, no pude encontrar nada sobre el cambio de comportamiento de su aplicación de iOS 10 a 11, podría considerar informar esto como un error ; por otro lado habiendo visto a la multitud de personas que encontraron este problema y el hecho de que afecta más o menos a todas las versiones recientes de iOS, sugeriría no usar position: fixed .

La solución más común es transform: translateZ(0) , esto no solo funciona en iOS y previene "cualquier posible flickering , sino que también obliga al navegador a utilizar aceleración de hardware para acceder a la GPU para hacer volar los píxeles . También debería funcionar sin el prefijo -webkit- desde iOS 9.