다른 일반 사용자인 제가 올바르게 이해했다면, 제가 꽤 자주 겪는 것과 같은 현상인 것 같습니다. 어떤 주제가 다시 로드되는 동안, 눈 깜짝할 사이에 포럼이 이전 게시글을 표시하다가 갑자기 마지막 방문 경계선으로 이동합니다. 방금 전에도 이런 일이 발생했는데, 저는 이동이 일어날 거라고 예상했지만, 오래된 게시글이 표시되다가 멈추었습니다.
그래서… 저는 코딩을 못 하지만, 이상한 타임아웃 스타일의 오류처럼 들립니다. 모든 것이 항상 경계 상태에 있는 것처럼, 아주 짧은 지연 현상 이후에 Discourse가 속도를 맞추려다 그 순간 화면에 있는 것을 표시하는 것 같습니다.
아니면 전혀 다른 문제일 수도 있겠네요 
이 문제는 로딩 슬라이더가 lock on 기능을 방해하는 것과 관련이 있어 보입니다.
“느린” 모드를 활성화하면 lockon이 게시물을 화면에 고정하기 위해 호출되는 것을 볼 수 있지만, 실제로 렌더링되는 모습은 보이지 않아 위치 지정이 크게 어긋나 있습니다.
LockOn 클래스 전체가 다소 해킹된 코드(hack)로 되어 있는데, 이 경우 위치를 고정하고 캐싱하는 대신 다른 방식을 사용하는 것이 나을 수도 있습니다. 이미 렌더링된 주제(topics)로 화면이 채워진 후에 lock on을 호출할 수 있는 메커니즘이 있을까요?
명확한 재현 단계를 알려주셔서 감사합니다 @Don 
네, 맞습니다! 여기서는 두 가지 일이 동시에 일어나고 있습니다.
still-loading 클래스를 제거해야 합니다.이 두 가지는 모두 Ember의 runloop에서 afterRender 부분에 예약되어 있었습니다. 그리고 ‘lock on’ 관련 작업이 기술적으로 먼저 예약되었기 때문에 먼저 실행되었습니다. 따라서 LockOn은 모든 게시글 HTML이 DOM에 있는 상태에서 실행되었지만, 여전히 display: none 상태였습니다. 
이 PR은 still-loading 클래스 제거를 runloop의 ‘render’ 부분으로 이동시킵니다. 이는 afterRender에서 작업을 예약하는 다른 모든 작업이 모든 것이 렌더링되고 가시화된 후에 실행됨을 의미합니다:
동의합니다! 이 버그 수정의 일부로 건드리고 싶지는 않았지만, 우리는 이러한 해킹(hack)들을 모두 제거하는 것을 목표로 해야 한다고 생각합니다.
파일 내의 주석들을 읽어보면, 원래 10년 전에 브라우저의 ‘스크롤 복원’ 기능을 상쇄하기 위해 도입된 것으로 보입니다. 요즘은 브라우저 기능을 비활성화하기 위해 history.scrollRestoration = false를 사용하므로, 대부분의 오래된 해킹(hack)은 불필요해졌다고 생각합니다.
아마도 이러한 민감한 변경 사항은 먼저 테마 컴포넌트를 통해 시험해 보고, 모든 것이 잘 작동하는지 확인한 후 코어에 병합하는 것이 가장 좋을 것입니다. LockOn을 제거하면 주제 스크롤 위치와 관련된 다른 많은 엣지 케이스도 해결될 것으로 예상됩니다. 향후 몇 주 내에 이를 시도해 볼 계획입니다 