Je dois admettre que c’est super difficile à reproduire ! c’est très incohérent et nous n’avons pas pu y trouver de schéma.
2 « J'aime »
@pmusaraj question rapide - pensons-nous que cela est lié à Discourse dans son ensemble ou à un thème spécifique ? Je n’ai pas pu le cerner à un seul composant pour le moment, mais je me demande si cela pourrait le résoudre ?
Je pense que ce n’est pas un thème ou un composant spécifique, cela a probablement à voir avec Discourse dans son ensemble. Je l’ai reproduit plus tôt cette semaine sur un site Discourse qui n’avait pratiquement aucun composant installé.
3 « J'aime »
Merci de partager ! C’est frustrant car l’expérience utilisateur est terrible à cause de cela et les utilisateurs doivent recharger la page ou revenir en arrière. J’essaie juste d’être proactif concernant une solution de contournement.
1 « J'aime »
Cela se produit avec le nouveau sous-domaine Discourse Discover (Safari sur ordinateur) :
Cela semble se produire de manière aléatoire, pas souvent. Existe-t-il un moyen d’exécuter un test de diagnostic lorsque cela se produit pour découvrir le problème ?
4 « J'aime »
D’après notre analyse jusqu’à présent, le sous-domaine du discours pense qu’il est toujours l’hôte et que tout actif/lien relatif est alors brisé. Cela signifie que sauf si vous utilisez un chemin absolu (par exemple, discourse.org/css/main.css au lieu de /css/main.css), cela fonctionnera. Mais c’est une solution de contournement assez folle car cela inclurait n’importe quelle icône, image, href, js, css, etc.
1 « J'aime »
Cela se produit à la fois sur ordinateur de bureau et sur mobile, uniquement pour Safari.
- Les parties de page requises (domaine externe) apparaissent toujours dans le journal de Discourse, alors qu’elles devraient être enregistrées sur le domaine externe. Impossible de déboguer quand cela se produit
- Une solution de contournement (au lieu de changer tout le CSS/JS/HREF en chemin absolu) consiste à placer \\u003cbase href="https://mydomain.com/\"\\u003e dans l’en-tête de toutes les pages pertinentes (sur le domaine externe)
2 « J'aime »
J’ai signalé un problème similaire avant d’être orienté vers celui-ci, qui semble lié.
Nous venons de passer à Discourse 3.2 il y a deux jours et depuis, nous recevons des signalements d’un problème similaire. Bien que ce ne soit pas lié au CSS dans notre cas, je pense que le problème est essentiellement le même.
Après avoir suivi un lien dans Discourse vers notre site Web principal, le navigateur pense toujours qu’il est sur le forum : l’URL dans le navigateur le dit (!), et parfois des liens (certains ? probablement relatifs) s’ouvrent dans le domaine du forum à la place, avec une erreur indiquant que la page du forum n’existe pas. Les signalements que nous avons jusqu’à présent concernent tous des iPhone/iPad. Je ne parviens pas du tout à le reproduire, mais ceux qui sont affectés semblent en faire l’expérience plusieurs fois par jour. En examinant les journaux de Discourse, je peux confirmer qu’il y a plusieurs requêtes 404 vers des pages qui n’existent que sur notre site Web principal.
Je suis assez perplexe que le navigateur ouvre un site Web et affiche l’URL d’un autre (sans iframes). S’agissant d’un bug de Safari, j’espère vraiment que cela se limite à un domaine de premier niveau, car les implications en matière de sécurité sont autrement assez désagréables.
Dans tous les cas, je pense qu’il faut garder à l’esprit que cela n’a commencé à se produire qu’après notre mise à niveau vers Discourse 3.2, donc quelque chose a changé depuis la 3.1 qui déclenche cela.
Peut-être une idée complètement farfelue, mais je me demande si cela pourrait être lié aux applications PWA et à la façon dont elles sont gérées par Safari ? Notre site Web principal déclare une application PWA – tout comme notre forum Discourse. Les deux sont standalone et avec start_url: \"/\" (le nôtre définit un id unique, mais Discourse ne le fait pas). À ma connaissance, les fichiers manifestes PWA ne spécifient pas d’hôte particulier sur lequel ils fonctionnent, donc je suppose qu’ils s’en tiennent à celui dans lequel ils sont hébergés. Dans notre cas, les deux PWA sont sur des sous-domaines distincts mais sur le même domaine ; la façon dont les navigateurs traitent cela pourrait laisser place à des erreurs et à la confusion du navigateur. Mais encore une fois, ce n’est qu’une supposition totale.
2 « J'aime »
S’il s’agit d’un lien courant (dans notre cas, c’est une icône de navigation en haut), peut-être qu’un target=_blank (ou même target=_top ?) peut servir de solution de contournement temporaire ?
Pour autant que je me souvienne, nous avons essayé cela ainsi que de remplacer HREF par une fonction JS qui exécutait window.open et le résultat était le même.
Rappelez-vous : il récupère la page externe - donc le DNS vers ce nouveau domaine fonctionne bien, cependant, il ne bascule pas vers ce domaine lors de l’exécution du script et de la récupération des ressources en chemin relatif de cette page. Donc, comme je l’ai dit, le HREF “de base” interne de Safari n’est pas mis à jour/basculé par la récupération de la page - ce qui fait qu’il charge en relatif par rapport au domaine “de base” actuel → 404.
Est-il possible de charger du JS ou du CSS de Discourse intentionnellement ?
J’ai essayé l’approche target=_blank et tous les rapports jusqu’à présent indiquent que le problème a disparu. Ce n’est pas parfait, mais c’est bien d’avoir une solution de contournement temporaire en attendant plus de clarté à ce sujet.
Soit dit en passant, cela ne se produit pas seulement lors d’un clic initié par l’utilisateur sur un lien, mais aussi lors d’une « redirection » JavaScript.
Nous utilisons l’authentification unique (SSO) sur notre forum et configurons la redirection de déconnexion avec l’URL du site web principal. Lorsqu’un utilisateur se déconnecte du forum et que Discourse les « redirige » vers notre site web principal, cela déclenche également le problème dans Safari. D’après un examen de la console, il ne s’agit pas d’une véritable redirection 302, donc peut-être d’un window.location.
Merci pour les discussions et le débogage ici, les amis.
Cette solution de contournement est suffisamment simple pour être essayée, je l’ai donc ajoutée à ce site (meta.discourse.org) via un composant de thème. Si cela résout le problème, ce serait assez intéressant car je soupçonne que cela peut aider les développeurs Webkit à déboguer le problème sous-jacent. (Et indépendamment, nous pouvons également évaluer l’ajout d’une balise base au cœur de Discourse par défaut.)
Ma compréhension est que la solution de contournement de la balise base peut aider lorsqu’elle est appliquée sur un site externe, car le problème semble se produire après avoir quitté un site Discourse.
Le test est-il effectué sur meta pour gérer le cas spécifique des liens entre deux instances Discourse différentes ? Ou bien me suis-je perdu quelque part (assez possible ! 
) ?
1 « J'aime »
Oui, notre problème le plus courant a été avec les liens entre deux instances de discourse. Je pense qu’il est possible que la solution de contournement de la balise base puisse également aider si elle est utilisée sur le site source (et que la destination n’est pas une instance de Discourse). Si le problème sous-jacent est que Safari/Webkit confond les URL de base (ce qui n’est pas trop loin de vos spéculations sur les PWA ci-dessus), alors l’ajout d’une base différente à l’un ou l’autre site pourrait aider à briser la mauvaise hypothèse qui est à la racine du problème ? Spéculation de ma part également, mais cela vaut la peine d’essayer.
1 « J'aime »
Est-ce que cela casse le bouton des messages directs ?
Cela n’a pas fonctionné pour moi jusqu’à ce que je désactive les thèmes en utilisant le mode sans échec.
1 « J'aime »
Bien vu, cela semble effectivement le casser. J’ai désactivé temporairement le composant avec la balise base.
3 « J'aime »
Bonjour 
Je ne sais pas si c’est nouveau ou pas, mais j’ai essayé maintenant ce qui se passe sur l’iPad. J’ai remarqué que cela se produit à chaque fois après un changement de page avec la navigation du navigateur ou un geste de balayage. Cela se produit parfois dans d’autres cas également. C’est très facile à reproduire sur la page d’accueil du thème Meta Branded. Avec les boutons de la barre de recherche.
Dans la vidéo, la première fois, je reviens avec la navigation du navigateur. La deuxième fois, je reviens avec un geste de balayage. La troisième fois, je reviens en cliquant sur le logo.
7 « J'aime »
Ouais, ces étapes reproduisent le problème à chaque fois pour moi sur Safari sur ordinateur. Bien joué @Don 
En texte :
-
Ouvrez meta.discourse.org dans Safari
-
Cliquez sur « Guides »
-
Revenez en arrière (en utilisant le bouton, le geste, le raccourci clavier, etc.)
-
Cliquez sur « Our Hosting », qui est un lien vers
discourse.org/pricing -
Observez la page cassée.
window.locationest toujoursmeta.discourse.org, mais le HTML provient dediscourse.org/pricing
9 « J'aime »