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

[DOA]

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

 

[DOA]

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

 

[beerForo]

I am able to reproduce.

 

[Mike]

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.

 

[DOA]

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?

 

[Rezpkt]

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

 

[Rezpkt]

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.

 

[KSA]

then press back in browser

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.

 

[KSA]

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.

Cache-Control - HTTP | MDN

The Cache-Control HTTP header field holds directives (instructions) — in both requests and responses — that control caching in browsers and shared caches (e.g. Proxies, CDNs).

developer.mozilla.org

 

[Rezpkt]

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

 

[beerForo]

I am able to reproduce.

I did not use the back button.

 

[Rhodium]

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.

 

[Rhodium]

Here is a video:

View attachment 2021.01.17-12.04.mp4

 

[Mike]

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:

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

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

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.

 

[Harpers Tate]

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.

 

[tvsbook.com]

The first time I used xenforo, I haven't found a solution yet.