Si mal no recuerdo, esto era esencial para algunos navegadores (¿IE < 10?) porque es imposible acceder a las etiquetas <noscript> a través de JavaScript después de hacer la detección de características. ¿Creo que @dan trabajó en este problema hace unos años?
Tenga en cuenta que actualmente hay dos ‘modos’ de recuperación:
Servir la vista del rastreador. No se requiere JS. Esto está limitado por browser_update_user_agents.
Servir la aplicación completa, detectar características y recuperarse moviendo el contenido de <noscript> a <body>. Esto no se basa en el agente de usuario.
El problema aquí es que (2) no funciona en dispositivos móviles, porque el servidor no está renderizando ningún contenido de <noscript>. Necesitamos solucionar eso, sin romper (1) para navegadores muy antiguos.
¿Cómo pensabas implementar (2) @sam? ¿Mantener una lista de ‘modernos’ coincisores de user agents en el núcleo? ¿Y luego los actualizamos como parte del ciclo de lanzamiento estable?
Parece que hay algunos comentarios que resolver, pero probablemente se fusionará en las próximas 24 horas. Actualizaremos aquí cuando lo esté. Luego, asumiendo que estás en tests-passed, podrás visitar /admin/upgrade en tu foro y aplicar el cambio.
Curiosamente, en un iPhone 5 en BrowserStack, haciendo proxy a local, veo una página en blanco incluso después de jugar con include_crawler_content? y establecerlo en true.
Puede que haya algunas cosas que Ember CLI esté haciendo localmente para romper estas pruebas.
Ciertamente parece roto según lo diseñado en iOS 7 en producción. (sin contenido porque no lo enviamos)
Será bastante complicado probar la solución, pero supongo que puedo simular algunas cosas localmente.
Esto debería cubrir alrededor del 95% de todo nuestro tráfico móvil, por lo que el ahorro de carga útil es significativo y el riesgo extremadamente bajo.
@Falco, ¿me olvido de algún navegador? Firefox es como una gota en el océano para Android, la gran mayoría parece estar simplemente en Chrome.
Parece que esto se ha vuelto a romper ayer. Estoy recibiendo una página en blanco sin mensaje de error a través de mi navegador y la aplicación en los mismos dos de tres foros
Sí, meta.discourse.org devuelve una página en blanco, al igual que community.jenkins.io, lo mismo que la queja original. Puedo confirmar que comenzó en algún momento del miércoles.
Eso ahora está implementado en Meta, y la mayoría de nuestros clientes alojados (incluido http://community.jenkins.io/). Los sitios ahora deberían cargarse de nuevo en iOS 12. ¡Gracias por informar del problema @wake y @Ian_W!
Excelentes noticias al ver que funciona de nuevo. Aprecio todos sus esfuerzos.
Solo una observación extraña ahora. Escribo la URL, presiono enter y la barra de progreso se completa lentamente. Luego, inicialmente, termino con una página en blanco, pero unos 6-7 segundos después, ¡aparece el contenido! Esto solía tardar aproximadamente un segundo (así que no se notaba antes). Extraño.
