Devo ammettere che è super difficile da riprodurre! è molto incoerente e non siamo riusciti a trovarne uno schema.
2 Mi Piace
@pmusaraj domanda veloce -
pensiamo che sia correlato a discourse nel suo complesso o a un tema specifico? Non sono ancora riuscito a individuarlo in un componente ma mi chiedo se questo possa risolverlo?
Penso che non si tratti di un tema o di un componente specifico, ma probabilmente ha a che fare con Discourse nel suo complesso. L’ho riprodotto all’inizio di questa settimana su un sito Discourse che aveva pochissimi componenti installati.
3 Mi Piace
Grazie per aver condiviso! Frustrante perché l’UX è terribile a causa di ciò e gli utenti devono ricaricare la pagina o tornare indietro. Sto solo cercando di essere proattivo riguardo a una soluzione alternativa.
1 Mi Piace
Si sta verificando con il nuovo sottodominio di discourse discover (desktop Safari):
Sembra che accada in modo casuale, non spesso. C’è un modo per eseguire un test diagnostico quando si verifica questo problema per scoprirne la causa?
4 Mi Piace
Sulla base della nostra analisi finora, il sottodominio discourse pensa di essere ancora l’host e quindi qualsiasi risorsa/link relativo è interrotto. Ciò significa che, a meno che non si utilizzi un percorso assoluto (ad esempio discourse.org/css/main.css invece di /css/main.css), funzionerà. Ma è una soluzione alternativa piuttosto folle in quanto includerebbe qualsiasi icona, immagine, href, js, css, ecc.
1 Mi Piace
Questo accade sia per Desktop che per mobile solo per Safari.
- Le parti della pagina richieste (dominio esterno) appaiono ancora nel log di Discourse, mentre dovrebbero essere registrate sul dominio esterno. Non sono riuscito a eseguire il debug di quando accade
- Una soluzione alternativa (invece di cambiare tutti i CSS/JS/HREF in percorso assoluto) è inserire \\u003cbase href="https://mydomain.com/\"\\u003e nell’intestazione di tutte le pagine pertinenti (sul dominio esterno)
2 Mi Piace
Ho appena segnalato un problema correlato prima di essere indirizzato a questo, che sembra essere correlato.
Abbiamo appena aggiornato a Discourse 3.2 due giorni fa e da allora riceviamo segnalazioni di un problema simile. Sebbene nel nostro caso non sia correlato al CSS, penso che il problema sia essenzialmente lo stesso.
Dopo aver seguito un link in Discourse al nostro sito web principale, il browser pensa ancora di essere sul Forum: l’URL nel browser lo indica (!), e talvolta i link (alcuni? probabilmente relativi) si aprono nel dominio del forum invece che nel sito principale, con un errore che indica che la pagina del forum non esiste. Le segnalazioni che abbiamo finora provengono tutte da iPhone/iPad. Non riesco a riprodurlo affatto, ma coloro che sono interessati sembrano riscontrarlo alcune volte al giorno. Guardando i log di Discourse, posso confermare che ci sono diverse richieste 404 a pagine che esistono solo sul nostro sito web principale.
Sono piuttosto perplesso dal fatto che il browser apra un sito web e mostri l’URL di un altro (senza iframe). Essendo un bug di Safari, spero vivamente che questo sia confinato all’interno di un dominio principale, poiché le implicazioni di sicurezza altrimenti sono piuttosto spiacevoli.
In ogni caso, penso che qualcosa da tenere a mente sia che questo ha iniziato ad accadere solo dopo l’aggiornamento a Discourse 3.2, quindi qualcosa è cambiato da 3.1 che sta innescando questo.
Forse un’ipotesi azzardata, ma mi chiedo se questo possa essere in qualche modo correlato alle app PWA e a come vengono gestite da Safari? Il nostro sito web principale dichiara un’app PWA, e così anche il nostro forum Discourse. Entrambi sono standalone e con start_url: "/". Per quanto ne so, i file manifest PWA non specificano un hostname particolare in cui operano, quindi presumo che rimangano legati a quello specifico in cui sono ospitati. Nel nostro caso, le due PWA si trovano in sottodomini separati ma nello stesso dominio; nel modo in cui i browser elaborano ciò, potrebbe esserci spazio per errori e confondere il browser. Ma ancora una volta, questa è solo un’ipotesi totale.
2 Mi Piace
Se si tratta di un link comune (nel nostro caso è un’icona di navigazione in alto), forse un target=_blank (o anche target=_top?) può servire come soluzione temporanea?
Per quanto ricordo, abbiamo provato anche quello, oltre a sostituire HREF con una funzione JS che eseguiva ‘window.open’ e ancora lo stesso risultato.
Ricorda: sta recuperando la pagina esterna, quindi il DNS verso questo nuovo dominio funziona bene, tuttavia, non passa a quel dominio durante l’esecuzione dello script e il recupero delle risorse con percorso relativo di quella pagina. Quindi, come ho detto, l’HREF “base” interno di Safari non viene aggiornato/modificato dal recupero della pagina, il che lo fa caricare rispetto al dominio “base” corrente → 404.
È possibile caricare JS o CSS da discourse intenzionalmente?
Ho provato l’approccio target=_blank e finora tutti i resoconti indicano che il problema è scomparso. Non è perfetto, ma è utile avere una soluzione temporanea finché non ci sarà maggiore chiarezza in merito.
Per quanto ne so, questo non accade solo quando l’utente fa clic su un link, ma anche con un “reindirizzamento” javascript.
Utilizziamo SSO sul nostro forum e impostiamo il logout redirect con l’URL del sito web principale. Quando un utente effettua il logout dal forum e Discourse lo “reindirizza” al nostro sito web principale, questo attiva anche il problema in Safari. Da un’occhiata alla console, non si tratta di un reindirizzamento 302 effettivo, quindi forse è un window.location.
Grazie per le discussioni e il debug qui, gente.
Questo workaround è abbastanza semplice da provare, quindi l’ho aggiunto a questo sito (meta.discourse.org) tramite un componente tematico. Se risolve il problema, sarebbe piuttosto interessante perché sospetto che possa aiutare gli sviluppatori Webkit a eseguire il debug del problema sottostante. (E, indipendentemente, possiamo anche valutare l’aggiunta di un tag base al core di Discourse per impostazione predefinita.)
La mia comprensione è che la soluzione alternativa del tag base possa aiutare quando viene applicata su un sito esterno, poiché il problema sembra verificarsi dopo aver lasciato un sito discourse.
Il test viene eseguito su meta per gestire il caso specifico dei collegamenti tra due diverse istanze discourse? O mi sono perso da qualche parte (molto possibile! 
)?
1 Mi Piace
Sì, il nostro problema più comune è stato con i link tra due istanze di discourse. Penso sia possibile che la soluzione alternativa del tag base possa aiutare anche se utilizzata sul sito di origine (e la destinazione non è un’istanza di Discourse). Se il problema sottostante è che Safari/Webkit confondono gli URL di base (questo non è troppo lontano dalle tue speculazioni sulla PWA sopra), allora aggiungere una base diversa a uno dei siti potrebbe aiutare a interrompere la supposizione errata che è alla radice del problema? Anche questa è una mia speculazione, ma vale la pena provare.
1 Mi Piace
Questo interrompe il pulsante dei DM?
Non ha funzionato per me finché non ho disabilitato i temi usando la modalità provvisoria.
1 Mi Piace
Ottima osservazione, sembra effettivamente che lo interrompa. Ho temporaneamente disabilitato il componente con il tag base.
3 Mi Piace
Ciao 
Non so se è una novità o meno, ma ho provato ora cosa succede su iPad. Ho notato che succede ogni volta dopo il cambio di pagina con la navigazione del browser o il gesto di scorrimento. A volte succede anche in altri casi. È molto facile da riprodurre sulla home page del tema Meta Branded. Con i pulsanti della barra di ricerca.
Nel video, la prima volta torno indietro con la navigazione del browser. La seconda volta torno indietro con il gesto di scorrimento. La terza volta torno indietro cliccando sul logo.
7 Mi Piace
Wow sì, questi passaggi riproducono il problema ogni volta per me su Safari desktop. Bel lavoro @Don 
In formato testuale:
-
Apri meta.discourse.org in Safari
-
Clicca su “Guides”
-
Torna indietro (usando il pulsante, il gesto, la scorciatoia da tastiera, ecc.)
-
Clicca su “Our Hosting”, che è un link a
discourse.org/pricing -
Osserva la pagina rotta.
window.locationè ancorameta.discourse.org, ma l’HTML proviene dadiscourse.org/pricing
9 Mi Piace