Browser issue Viewing second to last page of an unread thread marks it as read (not bold)

D

DOA

Member
Affected version
2.2
We found this issue on 2.1 and tested on this forum to confirm.

Go to a thread with multiple pages that are unread. (eg. What are you listening to in https://xenforo.com/community/forums/off-topic.7/)

You can view every page, go back and refresh and it will still be unread in bold as you haven't read the last page.

However, go to the second to last page, back and refresh and it will show as read.

Especially notice it with 2 page thread when you only read the first page and then it marks it as read
 
Forgot to say we replicated on our forum with the below

Bug: Android Chrome, Windows desktop Chrome, Windows Desktop Firefox, Windows desktop Edge
No bug: iPhone safari, iPhone Chrome
 
I quickly browsed around when this report came in and I think I saw it, but now I can't reproduce it. I also don't think there's anything in XF that would cause this. Our thread marking code is quite specifically based on the date of the last shown post. Are you still experiencing this? If so, if you can point to a thread here that reproduced it, that might help.

The only thing that comes to mind is some sort of attempt at preloading based on the rel=next value, though I'm really not clear on why that would happen cross browser.
 
I just did it again using the off topic forum and what are you listening to thread.

Second to last page and then press back in browser. It will be bold, but then refresh and it's not bold.

Android and chrome I'm using.

Are you using apple?
 
definitely a bug as i've just reproduced it on macos chrome.

it is as described - if you go to second to last page it will mark thread as read. please try some different browsers etc Mike you will find it
 
I just reproduced it on this forum as well as ours.

As said in the OP - go to your off topic node here and click the second to last page of what song you're listening to - then go back to the node and you'll see it has become unbolded / read.
 
DOA said:
then press back in browser
Click to expand...

Pressing the back button always serves from cache not newly updated timestamp. It is a browser behavior, not Xenforo. It is not a bug and I certainly do not want Xenforo to instruct browsers to serve a newly updated request when the back button is clicked. There is no reason to reload the page again, easy for quick navigation.
 
Mike said:
I quickly browsed around when this report came in and I think I saw it, but now I can't reproduce it. I also don't think there's anything in XF that would cause this. Our thread marking code is quite specifically based on the date of the last shown post. Are you still experiencing this? If so, if you can point to a thread here that reproduced it, that might help.

The only thing that comes to mind is some sort of attempt at preloading based on the rel=next value, though I'm really not clear on why that would happen cross browser.
Click to expand...
developer.mozilla.org

Cache-Control - HTTP | MDN

The HTTP Cache-Control header holds directives (instructions) in both requests and responses that control caching in browsers and shared caches (e.g., Proxies, CDNs).
developer.mozilla.org developer.mozilla.org
 
this isn't a cache issue. seems you have misunderstood

we are not talking about reading a thread in full, hitting back and it's still bold and then refresh and it's not bold (which is the browser cache yes)

we are talking about not reading a thread in full, hitting back, refreshing and it's not bold when it should be bold

its a bug in how xenforo works out if the thread is fully read or not, the fact it only happens on the second to last page, is possibly a good indicator to what's wrong
 
Last edited:
I can reproduce it, if a thread have 5 pages with something unread in last page and you go directly to page4, its marked as read even if you never visited page5.
 
I have managed to reproduce this now with dev tools open. It's essentially what I guessed: rel=next is being used as a prefetch/prerender hint in browsers. Ironically, this has been around for years and it discussed here:

developer.mozilla.org

Prefetch - MDN Web Docs Glossary: Definitions of Web-related terms | MDN

Prefetching refers to the practice of speculatively fetching documents or subresources in the background for pages that the user is likely to navigate to in the near future. This can significantly reduce the load time for the prefetched page if the user does choose to navigate to it...
developer.mozilla.org developer.mozilla.org

However, it looks like Chrome may have actually changed this recently because their expected prefetching bheavior wasn't working as expected:

1158209 - chromium - An open-source project to help move the web forward. - Monorail

bugs.chromium.org bugs.chromium.org

See comment 10 and 11. (And this report is virtually the same context as this reported bug.)

However, it looks like Chrome is disabling this behavior for version 88, based on the commit merged in comment 34.

The difficult thing here is that if we do want to forcibly block this behavior, we have to remove our rel=next references, and these can actually carry semantic value (not for SEO; Google hasn't used them for a number of years). They may have accessibility value, for example. As of Chrome 87, there don't appear to be any headers sent that distinguish a prefetch, whereas I believe Firefox may send (X-moz: prefetch), though I haven't confirmed that. Realistically, we just don't want the prefetch behavior at all for these situations, since the pages wouldn't be served from a cache anyway.

I'm going to leave this open for now, though I'm not totally sure what actions we may take yet, particularly as Chrome has reverted the behavior for the coming release.
 
Had a very similar issue with one of our Add-Ons (Moderator Checkpoint) which was marking content as checked in very similar circumstances to this "read" issue here, when it had never been even seen by the Moderator. That, too, appears to have been caused by pre-fetch. Initially it was seen only on Firefox (at least a year ago) but it recently began to manifest on Chrome and others, too. My suspicion is that browsers have changed their behaviour. That Add-On has been tweaked and its problem appears fixed.
 

Similar threads

NealC
Duplicate Moving a thread marks it as new but does not show in New Posts
Replies
3
Views
515
beerForo
beerForo
CTXMedia
Design issue Moving and thread marks it as unread
Replies
9
Views
1K
CTXMedia
CTXMedia
AdamD
  • Question Question
What's the proper way to read an unread thread?
Replies
6
Views
818
AdamD
AdamD
Back
Top Bottom