他のエンドユーザーである私が正しく理解していれば、それは私がしばしば経験していることと同じです。トピックが再読み込みされ、一瞬、まばたきする間か2回、フォーラムは古い投稿を表示してから最後の訪問境界にジャンプします。数分前に私に起こり、ジャンプを期待していましたが、古い投稿の表示は停止しました。
だから…コーディングはできませんが、それは奇妙なタイムアウトスタイルのエラーのように聞こえます。すべてが常に境界線状態にあり、非常に短い遅延インシデントの後、Discourseは追いつこうとして、その時点で画面にあるものを表示します。
それとも全く違うかもしれません😂
ローディングスライダーがロックオンに干渉しているように見えます。
「スロー」モードを有効にすると、投稿を画面にロックするためのロックオンが呼び出されているのがわかりますが、レンダリングされているのは見えないため、位置が非常にずれています。
LockOnクラス全体が少しハックです。この場合、位置をロックしてキャッシュする代わりに、何か別のことをすべきでしょうか？画面にレンダリングされたトピックがすでに表示された後にロックオンを呼び出すメカニズムはありますか？
@Don、明確な再現手順をありがとうございます 
はい、その通りです！同時に2つのことが起こっていました。
still-loading クラスを body から削除する必要があります。どちらも Ember の runloop の afterRender 部分でスケジュールされていました。そして、「lock on」関連の処理は技術的には最初にスケジュールされていたため、最初に実行されていました。そのため、LockOn は投稿の HTML がすべて DOM に存在している間に実行されていましたが、まだ display: none の状態でした。
この PR は、still-loading クラスの削除を runloop の「render」部分に移動します。これにより、「afterRender」で何かをスケジュールしている他のものはすべて、すべてがレンダリングされ表示された後に実行されるようになります。
同意します！このバグ修正の一部として、それに触れたくはありませんでしたが、これらのハックをすべて削除することを目指すべきだと思います。
ファイル内のコメントを読むと、元々は（10年前！）ブラウザの「スクロール復元」機能に対抗するために導入されたようです。現在では、 history.scrollRestoration = false を使用して そのブラウザ機能を無効にしているため、古いハックのほとんどは冗長になっていると思います。
おそらく、このような機密性の高い変更は、まずテーマコンポーネントを通じて試行するのが最善でしょう。そして、すべてがうまくいけば、コアにマージできます。LockOn を削除することで、トピックのスクロール位置に関する他の多くのエッジケースが修正されると想像しています。来週か再来週には試してみるつもりです 