認めざるを得ないのですが、再現が非常に困難です！非常に一貫性がなく、パターンを見つけることができませんでした。
「いいね！」 2
@pmusaraj 早速の質問ですが、これはDiscourse全体に関連するものですか、それとも特定のテーマに関連するものですか？まだ一つのコンポーネントに絞り込めていませんが、それが修正につながるかどうか考えていますか？
これは特定のテーマやコンポーネントではなく、Discourse全体に関わる問題だと思われます。今週初めに、コンポーネントがほとんどインストールされていないDiscourseサイトで再現しました。
「いいね！」 3
共有ありがとうございます！UXがひどいのでイライラします。ユーザーはページをリロードするか、戻る必要があります。回避策について先を見越して対応しようとしています。
「いいね！」 1
新しいディスコースのサブドメイン（Safariデスクトップ）で、以下のような現象が発生しています。
発生するのはランダムで、頻繁ではありません。この問題が発生した際に、原因を特定するための診断テストを実行する方法はありますか？
「いいね！」 4
これまでの分析によると、ディスコースのサブドメインはまだホストであると考えており、それゆえ相対的なアセット/リンクはすべて壊れています。つまり、絶対パス（例: /css/main.css の代わりに discourse.org/css/main.css）を使用しない限り、機能しません。しかし、これはアイコン、画像、href、js、cssなどをすべて含めることになるため、非常にクレイジーな回避策です。
「いいね！」 1
デスクトップとモバイルの Safari のみで発生します。
- 必須のページパーツ（外部ドメイン）が Discourse のログに表示されたままですが、外部ドメインに記録されるはずです。発生時のデバッグができません
- 1 つの回避策（すべての CSS/JS/HREF を絶対パスに変更するのではなく）は、関連するすべてのページ（外部ドメイン上）のヘッダーに
<base href="https://mydomain.com/">を配置することです
「いいね！」 2
私はちょうど関連する問題を報告したばかりで、それからこれに気づきました。これは関連しているようです。
2日前にDiscourse 3.2にアップグレードしたばかりで、それ以来同様の問題の報告を受けています。私たちのケースではCSS関連ではありませんが、問題は基本的に同じだと思います。
Discourse内のリンクを私たちのメインウェブサイトにたどった後、ブラウザはまだフォーラムにいると考えています。ブラウザのURLはそれを（！）示しており、時々（一部？おそらく相対的な）リンクはフォーラムドメインで開かれ、フォーラムページが存在しないというエラーが表示されます。これまでの報告はすべてiPhone/iPadからです。私はそれをまったく再現できませんが、影響を受けた人は1日に数回経験しているようです。Discourseのログを見ると、私たちのメインウェブサイトにのみ存在するページへの404リクエストがいくつかあることを確認できます。
ブラウザが1つのウェブサイトを開き、別のウェブサイトのURLを表示する（iframesなしで）ことに非常に困惑しています。Safariのバグであるため、これがトップドメイン内に限定されていることを願っています。そうでなければ、セキュリティへの影響は非常に深刻です。
いずれにしても、これはDiscourse 3.2にアップグレードした後でのみ発生し始めたことを念頭に置くべきだと思います。したがって、3.1以降でこれをトリガーする何かが変更された可能性があります。
完全な当て推量かもしれませんが、これがPWAアプリとSafariによるそれらの処理方法に何らかの形で関連しているのではないかと思いますか？私たちのメインウェブサイトはPWAアプリを宣言しており、Discourseフォーラムも同様です。どちらもstandaloneでstart_url: \"/\"を使用しています（私たちのものは一意のidを設定しますが、Discourseは設定しません）。私の知る限り、PWAマニフェストファイルは、それらが動作する特定のホスト名を指定しないため、ホストされている特定のホスト名に固執すると想定しています。私たちのケースでは、2つのPWAは別のサブドメインにありますが、同じドメインにあります。ブラウザがそれを処理する方法では、混乱を招き、ブラウザを混乱させる余地があるかもしれません。しかし、これも単なる推測です。
「いいね！」 2
もしこれが一般的なリンク（私たちの場合は上部にあるナビゲーションアイコン）からのものであれば、一時的な回避策として target=_blank（あるいは target=_top？）を使用できるのではないでしょうか？
私の記憶が正しければ、HREF を window.open を実行する JS:function に置き換えることも試しましたが、結果は同じでした。
思い出してください: 外部ページを 取得 しています。そのため、この新しいドメインへの DNS は正常に機能しますが、スクリプトを実行してそのページの相対パスリソースを取得する際に、そのドメインに切り替わりません。したがって、私が言ったように、内部 Safari の「ベース」HREF は、ページ取得によって更新/切り替えられないため、現在の「ベース」ドメインから相対的に読み込まれ、404 エラーになります。
Discourseから意図的にJSまたはCSSを読み込むことは可能ですか？
target=_blank アプローチを試したところ、これまでのところすべての報告で問題は解消されたとのことです。完璧ではありませんが、より明確になるまで一時的な回避策があるのは良いことです。
FWIW、これはユーザーがリンクをクリックしたときにのみ発生するのではなく、JavaScriptの「リダイレクト」でも発生します。
フォーラムでSSOを使用しており、logout redirectをメインウェブサイトのURLに設定しています。ユーザーがフォーラムからログアウトし、Discourseがメインウェブサイトに「リダイレクト」すると、Safariでも問題が発生します。コンソールを見ると、これは実際の302リダイレクトではなく、おそらくwindow.locationによるものです。
皆さん、議論とデバッグありがとうございました。
この回避策は試すのに十分簡単なので、テーマコンポーネントを介してこのサイト（meta.discourse.org）に追加しました。問題が解決すれば、根本的な問題をWebkit開発者がデバッグするのに役立つ可能性があるため、非常に便利です。（そして、独立して、デフォルトでDiscourseコアにbaseタグを追加することも評価できます。）
私の理解では、base タグの回避策は、問題がディスコースのウェブサイトを離れた後に発生するように見えるため、外部のサイトに適用された場合に役立つ可能性があります。
テストは、2つの異なるディスコースインスタンス間のリンクの特定のケースを処理するためにメタで行われていますか？それとも、どこかで迷ってしまいました（十分にありえます！
）？
「いいね！」 1
はい、最も一般的な問題は2つのDiscourseインスタンス間のリンクでした。baseタグの回避策は、ソースサイトで使用した場合（宛先がDiscourseインスタンスでない場合）にも役立つ可能性があると思います。根本的な問題がSafari/WebkitがベースURLを混同していることである場合（これは上記のPWAの推測からそれほど遠くありません）、どちらかのサイトに異なるベースを追加すると、問題の根幹にある誤った仮定を打破するのに役立つかもしれませんか？これも私の推測ですが、試してみる価値はあります。
「いいね！」 1
よく気がつきましたね。確かにそれは壊れているようです。一時的にbaseタグを持つコンポーネントを無効にしました。
「いいね！」 3
こんにちは:wave: 新しい情報かどうかわかりませんが、iPadで何が起こっているか試してみました。ブラウザのナビゲーションやスライドジェスチャーでページが変更された後に毎回発生することに気づきました。他のケースでも発生することがあります。Meta Brandedテーマのホームページで非常に簡単に再現できます。検索バーのボタンで発生します。
動画では、最初にブラウザのナビゲーションで戻ります。2回目はスライドジェスチャーで戻ります。3回目はロゴをクリックして戻ります。
「いいね！」 7
すごい、その手順でデスクトップ版 Safari で毎回問題を再現できます。@Don さん、素晴らしいです 
テキスト形式で：
-
Safari で meta.discourse.org を開きます。
-
「Guides」をクリックします。
-
戻ります（ボタン、ジェスチャー、キーボードショートカットなどを使用）。
-
discourse.org/pricingへのリンクである「Our Hosting」をクリックします。 -
壊れたページを観察します。
window.locationはmeta.discourse.orgのままですが、HTML はdiscourse.org/pricingのものです。
「いいね！」 9