# Topics jumping to wrong post
**URL:** https://meta.discourse.org/t/topics-jumping-to-wrong-post/276305
**Category:** Bug
**Created:** [August 23, 2023, 2:24pm UTC](https://meta.discourse.org/t/topics-jumping-to-wrong-post/276305 "2023-08-23T14:24:40Z")
**Posts on this page:** 4
**Page:** 2
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [August 25, 2023, 5:38pm UTC](https://meta.discourse.org/t/topics-jumping-to-wrong-post/276305/27 "2023-08-25T17:38:32Z")
> [@Don](#):
>
> I’ve got a _semi_ clear repro
If I, as another enduser, understood right it is same thing I’m experiencing quite often. Some topic is reloading and one short moment, an eye blink or two, forum is showing some older post and then jump to last visit border. It happened to me few moments ago and I was expecting jump, but it stopped showing an oldie.
So… I can’t code but that sounds like a strange timeout style’ish error - like everything is on the borderline state all the time and after very short lag incident Discourse tries keep pace and shows what ever is on screen at that moment.
Or not even close 😂
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [August 28, 2023, 7:46am UTC](https://meta.discourse.org/t/topics-jumping-to-wrong-post/276305/29 "2023-08-28T07:46:34Z")
This looks very much like a something todo with loading slider interfering with lock on.
When I enabled “slow” mode I can see lockon being called to lock a post onto the screen, but can not see it even rendered, so the positioning is super off.
The entire LockOn class is a bit of a hack, in this case maybe instead of locking and caching a position we do something else? Maybe there is a mechanism to call lock on later after the screen is already populated with rendered topics?
---
### Author:  [@david](https://meta.discourse.org/u/david)
#### Post date: [August 28, 2023, 11:11am UTC](https://meta.discourse.org/t/topics-jumping-to-wrong-post/276305/31 "2023-08-28T11:11:16Z")
Thanks so much for the clear reproduction steps @Don 🙏
> [@sam](#):
>
> loading slider interfering with lock on
Yup, that’s it! Two things going on here at the same time
1. Loading slider service needs to remove the `still-loading` class from the body
2. LockOn needs to scroll to the right place
They were both scheduled in the `afterRender` part of Ember’s runloop. And since the ‘lock on’ stuff is technically scheduled first, it was being run first. And so LockOn was running while all the post HTML was in the DOM, but still had `display: none`. 😬
This PR will move the `still-loading` class removal to the ‘render’ part of the runloop, which means anything else which is scheduling stuff `afterRender` will be running once everything is rendered **and visible** :
>
>
> When the 'loading slider' navigation indicator is enabled, and a connection is v…ery slow, we \`display: none\` most of the page and display a spinner. The \`still-loading\` body class for this was being added in the \`afterRender\` step in the Ember runloop. This meant that, depending on the order they were scheduled, other \`afterRender\` jobs may run before it. This caused an issue with topic scroll locations because we would attempt to scroll to an element which was \`display: none\` at the point its position was calculated.
>
> This commit moves the \`still-loading\` class manipulations to the \`render\` step of the runloop, which is technically more correct, and means that anything scheduled in the \`afterRender\` step is guaranteed to run without the \`display: none\` CSS.
>
> https://meta.discourse.org/t/276305/29
> [@sam](#):
>
> The entire LockOn class is a bit of a hack
Agreed! I didn’t want to touch it as part of this bugfix, but I think we should aim to remove all those hacks.
Reading the comments in the file, it looks like it was originally introduced (10 years ago!) to counteract browser ‘scroll restoration’ features. Nowadays, we [use `history.scrollRestoration = false`](https://developer.mozilla.org/en-US/docs/Web/API/History/scrollRestoration) to disable that browser feature, so I think that makes most of the old hacks redundant.
Probably best to trial this kind of sensitive change via a theme component first, and then if it all looks good we can merge into core. I imagine removing `LockOn` will fix a lot of other edge-cases we have with topic scroll position. I’ll aim to try this out in the next couple of weeks 🧑💻
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [August 29, 2023, 9:51pm UTC](https://meta.discourse.org/t/topics-jumping-to-wrong-post/276305/32 "2023-08-29T21:51:03Z")
[Previous page](https://meta.discourse.org/t/topics-jumping-to-wrong-post/276305.md?page=1)