Ne semble se produire que sur les appareils iOS - parfois les liens externes s’ouvrent dans la même fenêtre mais le CSS ne se charge pas. Étrange et je n’arrive même pas à le reproduire !
Cela ressemble à ceci :
J’ai également trouvé des rapports sur d’autres forums Discourse publics :
Puisqu’il a été signalé et corrigé auparavant, je me demande si cela pourrait être lié à un thème ou à un composant de thème peut-être ? J’apprécierais toute aide.
non, simplement parce que j’ai vu ce comportement plusieurs fois au cours des deux dernières semaines, uniquement sur mon iPhone et j’ai entendu la même chose de la part des utilisateurs, mais je ne peux pas le reproduire, cela semble aléatoire.
Cela ressemble à un ancien bug. Je ne peux pas le reproduire pour le moment et tous les sujets liés datent d’au moins un an. Il semble que le forum ne soit pas à jour.
J’essaie de le reproduire, il semble que cela se produise occasionnellement - je ne suis pas sûr de la façon de le reproduire. Cela se produit cependant, uniquement sur iOS, à ma connaissance.
Il semble que le comportement soit le même : cela se produit lors de l’ouverture d’un site web externe depuis Discourse. Par exemple, ouvrir https://discourse.org/ depuis meta.discourse.org.
Je pensais la même chose, cependant, cela semble se produire uniquement lorsque l’on clique depuis le forum et comme j’ai trouvé d’autres messages, j’ai pensé que quelqu’un pourrait éclairer ce point - cela pourrait être un problème iOS. Ce serait plus simple si le CSS ne se chargeait pas à chaque fois et seulement parfois
@Lilly Je me demande si vous pourriez partager comment discourse gère les href et s’il existe une méthode particulière pour iOS ? Cela semble être un problème lié à Safari, mais cela ne se produit que depuis discourse vers un autre domaine. Ce domaine n’est pas chargé comme si discourse essayait de charger localement le HTML de la page demandée.
Nous avons déjà essayé de forcer la politique no-cache et de jouer avec le préfixe www. Rien ne semble fonctionner. C’est exactement le problème mentionné ici :
Ils avaient le site principal chargé depuis leur community.URL.com, ce qui a causé le même chargement partiel de la page.
Depuis des mois, des utilisateurs d’iPhone nous signalent que lorsqu’ils cliquent sur des liens du sous-domaine (discourse) vers le site principal, la page peut ne pas charger le CSS ou le JS, mais seulement le HTML, la rendant ainsi inutilisable.
Cela ne se produit pas à chaque fois, mais suffisamment fréquemment pour qu’ils doivent recharger la page pour corriger le problème. En rechargeant, ils restent en fait sur discourse, ils doivent donc cliquer à nouveau.
En examinant le fichier access.log de nginx, nous pouvons constater que pour une raison quelconque, discourse essaie de charger les fichiers du domaine principal au lieu de l’index du domaine principal.
Il va sans dire que discourse ne possède pas ces fichiers, et la page est donc cassée.
Voici un extrait de “access.log” de nginx :
[19/May/2024:09:49:51 +0000] "here.domain.com" 176.76.227.47 "GET /js/cart/cart.js?v=0.32 HTTP/2.0" "Mozilla/5.0 (iPhone; CPU iPhone OS 17_4_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Ribblr Mobile" "-" 429 230 "https://here.domain.com/c/testing/17" - 0.000 "-" "-" "-" "-" "-" "-" "-"
[19/May/2024:09:49:51 +0000] "here.domain.com" 176.76.227.47 "GET /css/footer_and_header.css?v=1.13 HTTP/2.0" "Mozilla/5.0 (iPhone; CPU iPhone OS 17_4_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Ribblr Mobile" "-" 404 7963 "https://here.domain.com/c/testing/17" 0.019 0.019 "-" "-" "-" "-" "-" "-" "-"
[19/May/2024:09:49:51 +0000] "here.domain.com" 176.76.227.47 "GET /css/common/jssocials.css?v=0.03 HTTP/2.0" "Mozilla/5.0 (iPhone; CPU iPhone OS 17_4_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Ribblr Mobile" "-" 404 7968 "https://here.domain.com/c/testing/17" 0.020 0.020 "-" "-" "-" "-" "-" "-" "-"
[19/May/2024:09:49:51 +0000] "here.domain.com" 176.76.227.47 "GET /js/common/lightslider.js?v=0.14 HTTP/2.0" "Mozilla/5.0 (iPhone; CPU iPhone OS 17_4_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Ribblr Mobile" "-" 404 7980 "https://here.domain.com/c/testing/17" 0.020 0.020 "-" "-" "-" "-" "-" "-" "-"
[19/May/2024:09:49:51 +0000] "here.domain.com" 176.76.227.47 "GET /js/common/jssocials.js HTTP/2.0" "Mozilla/5.0 (iPhone; CPU iPhone OS 17_4_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Ribblr Mobile" "-" 404 7978 "https://here.domain.com/c/testing/17" 0.034 0.034 "-" "-" "-" "-" "-" "-" "-"
Nous avons essayé d’utiliser des liens href et window.reload(), mais le problème reste le même. Encore une fois, cela n’arrive qu’occasionnellement et uniquement pour les utilisateurs d’iPhone.
Des idées sur la raison pour laquelle cela se produit et comment y remédier ?
Quelques membres de l’équipe ont-ils des réflexions ? @Lilly Je sais que nous en avons discuté il y a quelques mois - peut-être avez-vous des éclaircissements supplémentaires à partager ?
Je pense que c’est le même problème que le site Web de discussion que j’ai partagé dans mon premier message.
Nous avons observé des problèmes étranges de ce type. D’après ce que nous pouvons dire, il doit s’agir d’un bug dans Safari/WebKit. Il devrait être impossible que ce type de rendu de « site mixte » se produise. Nous avons soumis un rapport à WebKit. (cc @pmusaraj)
Si quelqu’un peut trouver un moyen cohérent de reproduire le problème, cela aiderait très certainement à faire avancer le bug en priorité.
Des idées pour une solution de contournement de lien externe ?
Les deux HREF HTML et window.replace JS se comportent de la même manière
(Je suis sûr que les boutons Précédent/Suivant sont presque impossibles à outrepasser)
Malheureusement, je n’ai aucune idée de solution de contournement. J’ai essayé de désenregistrer les service workers au cas où ce serait la raison du conflit, mais cela n’a eu aucun effet.
Actuellement, je suis passé à Safari Technology Preview localement. Il semble ne pas avoir le problème, ce qui pourrait indiquer que cela est corrigé dans les nouvelles versions de Webkit. Ou, cela signifie qu’un navigateur vierge avec un cache vierge n’a pas les problèmes… difficile à dire.
Nous allons surveiller cela et continuer à chercher des solutions, le problème affecte plusieurs personnes dans l’équipe Discourse et sur différentes plateformes (macOS, iOS, application DiscourseHub). À moins de trouver une solution miracle, cependant, le mieux que nous puissions faire ici est de suivre le rapport de bug Webkit et d’y ajouter des informations supplémentaires, si pertinent/utile.