XpanderHappens with Chrome for me sometimes (haven't tested that long since its not my main browser).
Never seen it with Vivaldi, Opera (though they use same engine) and Firefox.
I can't reproduce it in Chromium or Firefox, but the longest comment thread I've had notifications for lately was the recent F1 2017 release article, and maybe it's not long enough to trigger it.
Okay I have two ideas I'm going to implement tonight to help track it down.
Currently clearing a notification and redirecting to a specific comment are done in the same page that renders an article. What i will do is split them up into two files. So we will have one to render that article as normal and one to actually do the notification clearing and redirect.
This way I can track down easier where the stall is coming from.
Here the F1 thread (the long one) is sufficient to trigger this behavior, I thought that is starts as soon as the notification point into the second page..
@liamdewe, thanks a lot for keeping keen to track this down. Note that I got this also when editing one of my posts in a longer thread on pages other than the first page (only with editing, never with initially posting). The editing itself is successful, but the redirect to the thread results in 5 minutes waiting for a response.
I'm still never seeing it myself, so it's a little difficult to track.
I've done an adjustment that might help, let me know.
Essentially, I wasn't doing a "die()" after sending the redirect header in php to send you to the correct comment. This results in the rest of the entire article rendering page still executing (possibly then stalling somehow). I've added them in, which should stop any unexpected behaviour.
Your adjustments seem to have effect, cool .
Clicking on a notifications link seem fine now and even much faster. I'll keep an eye out and report back.
Marked as solved, works perfectly now.
Due to spam you need to Register and Login to comment.