Ich muss zugeben, dass es sehr schwer zu reproduzieren ist! Es ist sehr inkonsistent und wir konnten kein Muster dafür finden.
@pmusaraj schnelle Frage – Glauben wir, dass das mit Discourse als Ganzes zusammenhängt oder mit einem bestimmten Thema? Ich konnte es noch nicht auf eine Komponente eingrenzen, aber ich überlege, ob das es beheben könnte?
Ich glaube, es ist kein spezifisches Thema oder eine Komponente, sondern hat wahrscheinlich mit Discourse als Ganzes zu tun. Ich habe es diese Woche auf einer Discourse-Seite reproduziert, auf der so gut wie keine Komponenten installiert waren.
Danke fürs Teilen! Frustrierend, weil die Benutzererfahrung dadurch schrecklich ist und Benutzer die Seite neu laden oder zurückgehen müssen. Ich versuche nur, proaktiv an einer Lösung zu arbeiten.
Dies geschieht mit der neuen Discourse Discover-Subdomain (Safari Desktop):
Es scheint zufällig zu passieren, nicht oft. Gibt es eine Möglichkeit, einen Diagnosetest durchzuführen, wenn dies auftritt, um das Problem aufzudecken?
Basierend auf unserer bisherigen Analyse glaubt die Discourse-Subdomäne, dass sie immer noch der Host ist, und dann ist jedes relative Asset/jeder Link defekt. Das bedeutet, es sei denn, Sie verwenden einen absoluten Pfad (z. B. discourse.org/css/main.css anstelle von /css/main.css), funktioniert es. Aber das ist ein ziemlich verrückter Workaround, da dies jedes Symbol, Bild, jede Verknüpfung, jedes JS, CSS usw. einschließen würde.
Dies geschieht sowohl für Desktop als auch für Mobilgeräte, aber nur für Safari.
- Erforderliche Seitenteile (externe Domain) werden immer noch in den Protokollen von Discourse angezeigt, obwohl sie auf der externen Domain protokolliert werden sollten. Konnte nicht debuggen, wann es passiert

- Eine Problemumgehung (anstatt alle CSS/JS/HREF in absolute Pfade zu ändern) besteht darin, \\u003cbase href="https://mydomain.com/\"\\u003e in den Header aller relevanten Seiten (auf der externen Domain) zu setzen

Ich habe gerade ein verwandtes Problem gemeldet, bevor ich darauf hingewiesen wurde, was damit zusammenzuhängen scheint.
Wir haben gerade vor zwei Tagen auf Discourse 3.2 aktualisiert und seitdem erhalten wir Berichte über ein ähnliches Problem. Obwohl es in unserem Fall nicht CSS-bezogen ist, denke ich, dass das Problem im Wesentlichen dasselbe ist.
Nachdem man einem Link in Discourse zu unserer Hauptwebsite gefolgt ist, denkt der Browser immer noch, er sei im Forum: Die URL im Browser besagt dies (!), und manchmal öffnen sich Links (einige? wahrscheinlich relative) auf der Forum-Domain statt, mit einer Fehlermeldung, dass die Forum-Seite nicht existiert. Die bisherigen Berichte stammen alle von iPhone/iPad. Ich kann es überhaupt nicht reproduzieren, aber die Betroffenen scheinen es ein paar Mal am Tag zu erleben. Wenn ich mir die Discourse-Protokolle ansehe, kann ich bestätigen, dass es mehrere 404-Anfragen an Seiten gibt, die nur auf unserer Hauptwebsite existieren.
Ich bin ziemlich verblüfft, dass der Browser eine Website öffnet und die URL einer anderen anzeigt (ohne iframes). Da es sich um einen Safari-Bug handelt, hoffe ich wirklich, dass dies nur innerhalb einer Top-Domain beschränkt ist, da die Sicherheitsimplikationen ansonsten ziemlich übel sind.
Auf jeden Fall denke ich, dass man bedenken sollte, dass dies erst nach dem Upgrade auf Discourse 3.2 aufgetreten ist, also hat sich seit 3.1 etwas geändert, das dies auslöst.
Vielleicht ein kompletter Schuss ins Blaue, aber ich frage mich, ob dies irgendwie mit PWA-Apps und deren Handhabung durch Safari zusammenhängen könnte? Unsere Hauptwebsite deklariert eine PWA-App – und unser Discourse-Forum auch. Beide standalone und mit start_url: "/". Soweit ich weiß, geben PWA-Manifestdateien keinen bestimmten Hostnamen an, in dem sie operieren, daher gehe ich davon aus, dass sie bei dem spezifischen Hostnamen bleiben, auf dem sie gehostet werden. In unserem Fall befinden sich die beiden PWAs auf separaten Subdomains, aber derselben Domain; in der Art und Weise, wie Browser dies verarbeiten, könnte es Raum für Verwirrung geben. Aber auch das ist nur eine reine Vermutung.
Wenn dies von einem gängigen Link stammt (in unserem Fall ist es ein Navigationssymbol oben), könnte vielleicht ein target=_blank (oder sogar target=_top?) als vorübergehende Umgehung dienen?
Soweit ich mich erinnere, haben wir das genauso versucht wie das Ersetzen von HREF durch eine JS:function, die ‘window.open’ machte, und immer noch das gleiche Ergebnis.
Denken Sie daran: Es ruft die externe Seite ab - also funktioniert DNS zu dieser neuen Domain einwandfrei, jedoch wechselt es nicht zu dieser Domain, während es das Skript ausführt und die Ressourcen mit relativen Pfaden dieser Seite abruft. Wie ich bereits sagte, wird die interne Safari-Basis-HREF nicht durch den Seitenabruf aktualisiert/gewechselt - was dazu führt, dass sie relativ zur aktuellen Basis-Domain geladen wird → 404.
Ist es möglich, JS oder CSS absichtlich von Discourse zu laden?
Ich habe den target=_blank-Ansatz ausprobiert und alle bisherigen Berichte besagen, dass das Problem behoben ist. Nicht perfekt, aber es ist gut, einen vorübergehenden Workaround zu haben, bis es mehr Klarheit gibt.
FWIW, dies geschieht nicht nur bei einem vom Benutzer initiierten Klick auf einen Link, sondern auch bei einer JavaScript-“Umleitung”.
Wir verwenden SSO in unserem Forum und richten die logout redirect mit der URL der Hauptwebsite ein. Wenn sich ein Benutzer aus dem Forum abmeldet und Discourse ihn auf unsere Hauptwebsite “umleitet”, wird dies auch in Safari ausgelöst. Bei einem Blick in die Konsole handelt es sich nicht um eine tatsächliche 302-Umleitung, daher vielleicht ein window.location.
Vielen Dank für die Diskussionen und das Debugging hier, Leute.
Dieser Workaround ist einfach genug, um ihn auszuprobieren, daher habe ich ihn über eine Theme-Komponente zu dieser Website (meta.discourse.org) hinzugefügt. Wenn er das Problem behebt, wäre das ziemlich raffiniert, da ich vermute, dass er Webkit-Entwicklern helfen kann, das zugrunde liegende Problem zu debuggen. (Und unabhängig davon können wir auch prüfen, ob ein base-Tag standardmäßig zu Discourse-Core hinzugefügt werden soll.)
Mein Verständnis ist, dass der base-Tag-Workaround helfen könnte, wenn er auf einer externen Website angewendet wird, da das Problem anscheinend nach dem Verlassen einer Discourse-Website auftritt.
Wird der Test auf Meta durchgeführt, um den spezifischen Fall von Links zwischen zwei verschiedenen Discourse-Instanzen zu behandeln? Oder habe ich mich irgendwo verirrt (ziemlich möglich!
)?
Ja, unser häufigstes Problem waren Links zwischen zwei Discourse-Instanzen. Ich denke, es ist möglich, dass die base-Tag-Umgehung auch helfen könnte, wenn sie auf der Quellseite verwendet wird (und das Ziel keine Discourse-Instanz ist). Wenn das zugrunde liegende Problem darin besteht, dass Safari/Webkit die Basis-URLs verwechselt (das ist nicht allzu weit von Ihren PWA-Spekulationen oben entfernt), dann könnte das Hinzufügen einer anderen Basis zu einer der beiden Seiten helfen, die falsche Annahme zu brechen, die der Ursache des Problems zugrunde liegt? Spekulation meinerseits, aber es ist einen Versuch wert.
Beschädigt dies die Schaltfläche “DMs”?
Bei mir hat es nicht funktioniert, bis ich die Themes im abgesicherten Modus deaktiviert habe.
Gut bemerkt, es scheint tatsächlich, dass es es kaputt macht. Ich habe die Komponente mit dem base-Tag vorübergehend deaktiviert.
Hallo
Ich weiß nicht, ob das neu ist oder nicht, aber ich habe es jetzt auf dem iPad ausprobiert. Mir ist aufgefallen, dass es jedes Mal passiert, nachdem die Seite mit der Browser-Navigation oder einer Wischgeste wechselt. Manchmal passiert es auch in anderen Fällen. Es ist sehr leicht auf der Homepage des Meta Branded-Themes reproduzierbar. Mit den Suchleisten-Buttons.
Im Video gehe ich das erste Mal mit der Browser-Navigation zurück. Das zweite Mal gehe ich mit einer Wischgeste zurück. Das dritte Mal gehe ich zurück, indem ich auf das Logo klicke.
Wow ja, diese Schritte reproduzieren das Problem jedes Mal auf meinem Desktop-Safari. Gut gemacht @Don ![]()
In Textform:
-
Öffnen Sie meta.discourse.org in Safari
-
Klicken Sie auf „Guides“
-
Gehen Sie zurück (mit der Schaltfläche, Geste, Tastenkombination, was auch immer)
-
Klicken Sie auf „Our Hosting“, was ein Link zu
discourse.org/pricingist -
Beobachten Sie die kaputte Seite.
window.locationist immer nochmeta.discourse.org, aber das HTML stammt vondiscourse.org/pricing

