Se non ricordo male, questo era essenziale per alcuni browser (IE < 10?) perché è impossibile accedere ai tag <noscript> tramite JavaScript dopo aver eseguito il feature detection. Penso che @dan abbia lavorato su questo problema qualche anno fa?
Nota che al momento ci sono due ‘modalità’ di fallback:
Fornire la vista crawler. Nessun JS richiesto. Questo è bloccato su browser_update_user_agents.
Fornire l’app completa, fare il feature detection e il fallback spostando il contenuto <noscript> in <body>. Questo non si basa sull’user agent.
Il problema qui è che (2) non funziona sui dispositivi mobili, perché il server non sta renderizzando alcun contenuto <noscript>. Dobbiamo risolvere questo problema, senza compromettere (1) per i browser molto vecchi.
Come pensavi di implementare (2) @sam? Mantenere un elenco di matcher per user agent ‘moderni’ nel core? E poi aggiornarli come parte del ciclo di rilascio stabile?
Sembra che ci siano alcuni commenti da risolvere, ma probabilmente verrà unito nelle prossime 24 ore. Aggiorneremo qui quando sarà fatto. Quindi, presumendo che tu sia su “tests-passed”, potrai visitare /admin/upgrade sul tuo forum e scaricare la modifica.
Interessante, su un iPhone 5 nel browser stack, in proxy a locale, vedo una pagina bianca anche dopo aver armeggiato con include_crawler_content? e impostato su true.
Potrebbe esserci qualcosa che ember cli sta facendo in locale per rompere questo test.
Certamente sembra rotto come progettato su iOS 7 in produzione. (nessun contenuto perché non lo spediamo)
Sarà ragionevolmente complicato testare la correzione, ma immagino di poter fingere alcune cose in locale.
Questo dovrebbe coprire circa il 95% di tutto il nostro traffico mobile, quindi il risparmio sul payload è significativo e il rischio estremamente basso.
@Falco mi sto dimenticando qualche browser? Firefox è come una goccia nell’oceano per Android, la stragrande maggioranza sembra essere semplicemente su Chrome.
5 Mi Piace
david
(David Taylor)
Ha separato questo argomento il
71
Sì, meta.discourse.org restituisce una pagina vuota, così come community.jenkins.io, lo stesso del reclamo originale. Posso confermare che è iniziato mercoledì.
Questo è ora distribuito su Meta e la maggior parte dei nostri clienti ospitati (incluso http://community.jenkins.io/). I siti dovrebbero ora caricarsi di nuovo su iOS 12. Grazie per aver segnalato il problema @wake e @Ian_W!
Ottime notizie nel vedere che funziona di nuovo. Apprezzo tutti i vostri sforzi.
Solo un’osservazione strana ora. Digito l’URL, premo invio e la barra di avanzamento si completa lentamente. Poi inizialmente finisco con una pagina bianca, ma circa 6-7 secondi dopo, appare il contenuto! Questo prima richiedeva solo circa un secondo (quindi non era molto evidente prima). Strano.
