Si ma mémoire est bonne, c’était essentiel pour certains navigateurs (IE < 10 ?) car il est impossible d’accéder aux balises <noscript> via JavaScript après avoir effectué la détection de fonctionnalités. Je pense que @dan a travaillé sur ce problème il y a quelques années ?
Notez qu’il existe actuellement deux ‘modes’ de repli :
Servir la vue du robot d’exploration. Aucun JS requis. Ceci est conditionné par browser_update_user_agents.
Servir l’application complète, détecter les fonctionnalités, et se replier en déplaçant le contenu <noscript> dans <body>. Ceci n’est pas basé sur l’agent utilisateur.
Le problème ici est que (2) ne fonctionne pas sur mobile, car le serveur ne rend aucun contenu <noscript>. Nous devons corriger cela, sans casser (1) pour les navigateurs très anciens.
Je suggère que nous mettions à jour les étapes pour :
Comment pensiez-vous implémenter (2) @sam ? Maintenir une liste de correspondances d’agents utilisateurs « modernes » dans le noyau ? Et ensuite, nous les augmenterons dans le cadre du cycle de publication stable ?
Oui, quelque chose comme ça, pour être honnête, cette semaine ne s’annonce pas très prometteuse pour moi, je n’arrive pas à dégager beaucoup de temps de programmation.
Je vais probablement transmettre ce travail, votre plan d’action modifié semble excellent.
Il semble qu’il y ait des commentaires à résoudre, mais cela sera probablement fusionné dans les prochaines 24 heures. Nous mettrons à jour ici lorsque ce sera le cas. Ensuite, en supposant que vous êtes sur tests-passed, vous pourrez visiter /admin/upgrade sur votre forum et intégrer le changement.
Fait intéressant, sur un iPhone 5 dans BrowserStack, en passant par un proxy vers le local, je vois une page blanche même après avoir joué avec include_crawler_content? et l’avoir mis à true.
Il se peut que des éléments d’Ember CLI fassent quelque chose en local qui casse ce test.
Cela semble certainement cassé comme prévu sur iOS 7 en production. (pas de contenu car nous ne le livrons pas)
Ce sera assez délicat de tester la correction, mais je suppose que je peux simuler certaines choses en local.
Cela devrait couvrir environ 95 % de notre trafic mobile, donc l’économie de charge utile est significative et le risque extrêmement faible.
@Falco est-ce que j’oublie des navigateurs ? Firefox est comme une goutte d’eau dans l’océan pour Android, la grande majorité utilise simplement Chrome, semble-t-il.
Cela semble s’être à nouveau cassé hier. J’obtiens une page blanche sans message d’erreur via mon navigateur et l’application sur les mêmes deux forums sur trois
Oui, meta.discourse.org renvoie une page blanche, tout comme community.jenkins.io, identique à la plainte initiale. Je peux confirmer que cela a commencé mercredi.
Ceci est maintenant déployé sur Meta, et la majorité de nos clients hébergés (y compris http://community.jenkins.io/). Les sites devraient maintenant se charger à nouveau sous iOS 12. Merci d’avoir signalé le problème @wake et @Ian_W !
Excellente nouvelle de voir que cela fonctionne à nouveau. J’apprécie tous vos efforts.
Juste une observation étrange maintenant. Je tape l’URL, j’appuie sur Entrée et la barre de progression se termine lentement. Ensuite, je me retrouve initialement avec une page blanche, mais environ 6 à 7 secondes plus tard, le contenu apparaît ! Cela prenait auparavant à peu près une seconde (donc pas vraiment perceptible avant). Bizarre.
