Partial fix Alerts don't redirect you to the newest reply sometimes

sbj

Well-known member
Affected version
2.1
Hello,

sometimes when I click on an alert, it doesn't redirect me to the newest reply. Often for a thread with a lot of images. Not sure if this is a CDN issue or caching issue or a bug.

As an example:

203625

When I click on the alert which is at the top, it should direct me to the post with number 1352972 as you see on the left bottom corner.

This is the post: https://xenforo.com/community/threa...r-xenforo-2-x-paid.134528/page-4#post-1352972

Now watch this gif to see what happens (you can click on the gif to enhance it):



As you see me clicking on the alert, it should redirect me to the last reply of that thread and it doesn't.
Then I scroll down to the bottom and click on the post myself, and again it loads back to the middle of the thread instead of showing me the post I clicked on.
 
It's a tricky one. Generally, it shouldn't happen and in my testing on iOS and Chrome it doesn't. There may be specific conditions where it does happen, such as a slow connection, but certainly there is code to prevent and rectify it. It's to do with the way the browser takes you to a specific point in the page, but then that position ends up getting offset by the large items (like images, embeds) being loaded in.

We'll keep an eye on it, but there may not be much more we can do.
 
I'm at home right now and using my PC which is connected by LAN (200 mbit/s).
Honestly, I am encountering this problem for a very long time but I never reported it. Thought today I report it finally because it is annoying sometimes. Thanks for looking into it.
 
I came to do some work on this today and I was unable to reproduce it with the provided thread.

Is this still happening for you in Firefox 69 or Firefox 70?

Maybe it's just so intermittent I just haven't come across it.
 
Firefox 69.0.3 on Windows 8.1.

Yep, still happening here.

I clicked on the provided link, first try it landed correctly on that message. Then I went back and tried again, and the same problem occurs. I then tried 3-4 more times and all of them don't land on the correct post. Even clicking the post nr. 73 on that provided link's thread moves me between post nr. 66 and post nr. 67

I also clicked on post nr. 67, all fine, then clicked on post nr. 68, it scrolled back again. I am not sure why it sometimes lands correctly and why sometimes it does not. I can provide another screen cap if you want me to.
 
Last edited:
I've run into this. It's when things load after the page loads and it jumps. If there are twitter embeds, it definitely happens:


Adding this JS can help at end of your pages:

Code:
<script>
if (window.location.hash.length > 0) { setTimeout(function() { window.scrollTo(0, $(window.location.hash).offset().top); }, 1000); }
</script>

It reorients the page after a time delay. It's set to 1 second there. Adjust as you see fit. It does cause another jump... but better than being lost on the page.
 
I've run into this. It's when things load after the page loads and it jumps. If there are twitter embeds, it definitely happens:
We know about that and there is a separate bug report for it.

It reorients the page after a time delay. It's set to 1 second there. Adjust as you see fit. It does cause another jump... but better than being lost on the page.
We already have a better solution and it works for images (for everyone apart from sbj, evidently). You can see it in action in the js/xf/core.js file in the pageLoadScrollFix function.

It's true that your solution would be potentially more effective for the embedded content case but it could also feel a little janky. If everything loads on 0.1 seconds then you start scrolling down the page then 0.9 seconds later it would scroll back to where you started, for example.

Anywho, as I say there's another thread about that specifically here:

I'm not sure how feasible a solution is as it involves knowing when externally hosted asynchronous content has finished loading, but watch the thread above.
 
for everyone apart from sbj, evidently
Well, if it is only me who is affected, then it might be because of my adblockers or something with my Firefox installation (maybe cookies?).

I tested within private window on Firefox and the site reloads much quicker, is more sharp and I couldn't create the same bug on that provided link.
However, your message on this thread is nr.9 and when I clicked on the last reply on the forum_list, it directed me to post nr. 8.
I tested this now 3 times. Opened 3 private windows and everytime the first time it scrolled to post nr.8. After that everything worked like normally.

Maybe it is just me, then it should be okay, if it doesn't affect regular users.
 
It's still happening to me - with Chrome - and to a lot of people on my forum. The alert takes me to the last thing I read previously and then I have to scroll down from there. So every time I click on an alert, I have to scroll past the previous new replies that I read the last time I clicked on an alert.

If you like I'll be happy to poll people on what browser they're using when this happens, but so far as I can tell the browser doesn't matter.
 
he alert takes me to the last thing I read previously and then I have to scroll down from there.
Ahh, that is a good catch. That might be the answer to the problem. This is why I can reproduce the bug but others cannot for the provided link above, because they haven't had the alert I got previously. So for me it jumps back to the place I read previously long time ago, while others don't have that mark. Makes sense! Hope this helps the devs to figure it out.
 
The alert will take you to the content that the alert refers to. Whether you have read beyond that doesn’t matter so I’m not sure what the relevance of this is.
 
The alert will take you to the content that the alert refers to. Whether you have read beyond that doesn’t matter so I’m not sure what the relevance of this is.
He means like when he gets multiple alerts for the same thread, the latest alert doesn't take him to the latest post. He lands on a place where a previous alert placed him previously.

See my gif for example. I am clicking on the latest alert and it should take me to post nr. 73 because the alert refers to that place. However I land on a previous place.

1571325837489.png

So, it seems that because of caching or cookies or sth else, the page brings you back to a place I was previously.
This is probably why you cannot reproduce this bug for the given link from above. You never received an alert previously for this thread. There is no saved state for you for that thread. When you click on that link, you just land perfectly on the last reply the link is refering to.
I, however, received alerts for that thread previously. When I click on it, the page places me on a previous state I was before when I received a previous alert.

Hope this makes more sense to you.
 
There isn't really any concept of "memory" in terms of XF in these cases, though different browsers do have different approaches to handling scroll position across navigations.

However, generally speaking, this issue relies on browser scroll anchoring implementations. This is implemented in Chrome and Firefox (though Firefox seems less consistent in some of my tests) and we have made some tweaks to make this function a bit better in XF:


As it stands, beyond that, there isn't much more we can do to prevent this with arbitrary embeds. I expanded a bit more in the linked post. I'll call this partially fixed, though as noted it is now relying on a browser feature in these cases, so if it doesn't work as expected, this may be an underlying browser issue/limitation.
 
I am encountering weird issues since yesterday, probably related to this.

I get alerts, I use my mouse wheel button to open them as new tabs on my Firefox browser, and some tabs are blank pages (not loaded pages) and some are opened but the screen is on the buttom of the page (and not anchored to the text which the alert should have sent me to).

Will open a new bug if I can reproduce it, just wanted you to know.
 
That'd very likely be unrelated -- the only change we made here is actually quite small (and if the browsers are working correctly, only actually changes one particular case).
 
Top Bottom