iOS ne charge pas toujours le CSS lors de la navigation entre sous-domaines

Merci @Don, 100% reproductible pour moi aussi. Les tests effectués avec BrowserStack montrent qu’il s’agit d’une régression après Safari 17. Je n’ai pas de reproductibilité sur Ventura (Safari 16.5), mais je peux reproduire sur Sonoma (Safari 17.3). J’ai signalé les étapes et les conclusions ci-dessus en amont à Webkit, cela devrait les aider à résoudre ce problème.

8 « J'aime »

Ouais, étapes reproductibles ! :clap:

Peut également le reproduire facilement dans notre forum (3.2.4). La clé semble être la navigation arrière, car cela déclenche le bug, quelle que soit la page initiale ou intermédiaire (j’ai essayé le sujet, la catégorie, la FAQ, les badges, etc.).

Pendant que Webkit examine cela (j’imagine qu’il faudra un certain temps pour qu’une correction atteigne une version de production), serait-il judicieux d’essayer de cerner le changement particulier dans Discourse à partir duquel il a commencé à apparaître le bug dans Safari et, si c’est simple et réalisable, potentiellement avoir une solution de contournement locale ? Dans notre cas, il n’a commencé à apparaître qu’après notre récente mise à jour de 3.1.5 vers la dernière version stable. Une grande fenêtre, mais peut-être parcourir les bêtas d’abord et partir de là ?

2 « J'aime »

PS : Juste pour ajouter que, maintenant que je peux le reproduire, j’ai essayé de désactiver temporairement le PWA sur notre site Web principal et cela n’a pas semblé faire de différence. Donc… ce n’est pas lié au multi-PWA.

J’ai donc essayé sur Chrome aussi et j’ai remarqué quelque chose de vraiment étrange. Si je comprends bien, cela ne devrait se produire que sur Safari ? Je le pensais, mais peut-être que je me trompe. Parce que je peux le reproduire aussi dans le navigateur Chrome sur iPad. Il semble donc que le problème vienne de l’OS ? Est-ce également reproductible sur MacOS sous Chrome ? :thinking: Ou cela n’affecte-t-il que iOS et iPadOS sur Chrome aussi à cause du problème webkit ?

Ma compréhension est qu’Apple n’autorise pas les navigateurs tiers sur iOS/iPadOS, donc Chrome/Firefox/etc ne sont qu’une interface graphique spécialisée, utilisant tous Webkit pour rendre les pages en arrière-plan.

Comme le problème concerne Webkit, tout navigateur fonctionnant sous iOS/iPadOS est affecté.

6 « J'aime »

Oui, c’est ça :+1: Bien que cela change Using alternative browser engines in the European Union - Support - Apple Developer

3 « J'aime »

Merci de nous avoir relancés à ce sujet @mentalstring, après avoir divisé, je pense qu’il y a un coupable très probable dans : DEV: Change default of `cross_origin_opener_policy_header` (#24940) · discourse/discourse@38abc0d · GitHub

D’après un test sur l’une de nos instances, exécuter SiteSetting.cross_origin_opener_policy_header = 'unsafe-none' dans la console Rails ou ajouter ceci à votre ENV :

DISCOURSE_CROSS_ORIGIN_OPENER_POLICY="unsafe-none"

résout le problème. Ce paramètre de site est une mesure de renforcement de la sécurité, nous évaluons les avantages et les inconvénients de la mise à jour du cœur également, mais si vous (et d’autres suivant ce problème) pouviez essayer cela de votre côté, ce serait formidable, cela nous donnerait plus de confiance que c’est bien le changement sous-jacent dans Discourse.

3 « J'aime »

Ah, le voilà alors ! :+1:
Je peux confirmer que le réglage de COOP sur 'unsafe-none' a effectivement arrêté l’apparition du bug sur notre instance 3.2.4. Le remettre sur same-origin-allow-popups le fait revenir immédiatement.
C’est bien d’avoir une sorte de solution de contournement temporaire. Pendant ce temps, j’imagine que c’est une information probablement utile à signaler à l’équipe Webkit, car cela pointe vers quelque chose de spécifique qui le déclenche.
PS : Merci d’avoir examiné cela et désolé pour le harcèlement – j’essaie juste maladroitement d’aider notre communauté. :sweat_smile:

2 « J'aime »

Juste pour éviter que d’autres ne le manquent aussi, cette partie devrait être :

DISCOURSE_CROSS_ORIGIN_OPENER_POLICY_HEADER: unsafe-none

1 « J'aime »

Une suite ici les amis : un développeur WebKit a fusionné un correctif pour ce problème il y a quelques semaines. J’ai essayé de le tester en utilisant les builds nocturnes de WebKit, malheureusement, je peux toujours reproduire le problème. Cependant, je fais peut-être quelque chose de mal. J’attendrai la prochaine version de Safari Technology Preview (elle devrait arriver bientôt) pour tester à nouveau, j’espère qu’elle est bien corrigée. (Le rapport de bug WebKit est ici.)

2 « J'aime »

Malheureusement, cela n’est toujours pas corrigé dans la dernière version de Safari sur Sequoia. J’ai rouvert le rapport de bug Webkit en amont lié ci-dessus.

4 « J'aime »

Bonne nouvelle, il y a un correctif en amont et il a fonctionné sur ma machine en utilisant les archives de build WebKit. Il faudra encore quelques semaines avant que cela n’arrive d’abord à Safari Technology Preview, puis à Safari en général.

7 « J'aime »

l’avez-vous testé ?

Oui, en effet.

Il semble que cela ait finalement été inclus dans Safari Technology Preview, version 209 (Safari 18.2, WebKit 20621.1.6).

J’aimerais avoir une confirmation de la part d’autres utilisateurs sur ce sujet avant de clore. Merci d’avance !

2 « J'aime »

J’ai juste essayé avec la version 210 et je peux confirmer que le problème ne se produit plus sur notre forum (en version stable) avec Safari TP, alors qu’il se produit toujours avec la version actuelle de Safari. :+1:

Avez-vous une idée du temps que cela peut prendre pour qu’il arrive dans la version principale de Safari ?

1 « J'aime »

Je suppose que ce sera dans la prochaine version de Safari, probablement dans quelques semaines. Merci pour vos tests !

1 « J'aime »

On dirait que c’est effectivement corrigé dans Safari 18.3 !

6 « J'aime »

Ce sujet a été automatiquement fermé après 3 jours. Les nouvelles réponses ne sont plus autorisées.