News:

SMF 2.1.4 has been released! Take it for a spin! Read more.

Main Menu

Ask help for strange issue about "new" label/tag

Started by Sebastiii, December 06, 2020, 02:27:22 PM

Previous topic - Next topic

prefertolurk

 I have been experiencing this bug on the hxxp:nasaspaceflight.com [nonactive] forum (2.0.15) for a few weeks now.  I have done a decent amount of testing, and I am able to replicate it at home and at work -- both Chrome and windows 10 setups.  There are a few others on that forum that are also reporting the bug in our local bug report forum.  This is what I have found through my testing:

If there is a forum thread that has 20 pages and my last unread post was on page 19, and then I click the "new" tag, It will take me directly to the oldest unread post on page 19. (as expected) If I go back to the listing of threads, the new tag will still be on that thread, but if I click it, it will take me to the top of page 20. If I go back one more time, the new tag is gone.  (this behavior is all as expected)

The bug, is that this exact same behavior is happening to the thread below the one I am reading as well.  So if I have only one unread page in the thread beneath the one I am reading, clicking the new tag will immediately clear the new tag from the thread below. If I have two pages of unread posts in that thread, clicking the new tag will only clear that first page of posts as unread and the new tag on the other thread will still be there, but now it wont take me to the correct page. 

It is literally behaving as if I am clicking the new tag on both threads at the same time.

I am a C# programmer by trade, but I know enough about javascript to give myself headaches trying to read it.  If I had to guess though, there is a bug in one of the places that iCurMessageId is being set.

That's about all the digging I can do before my overwhelming sense of pity for javascript developers overwhelms my ability to debug any farther. :-) I salute you, javascript devs. 

Good hunting.

Sebastiii

Thanks @prefertolurk, this is the issue (started on 23/11 for me lol)

So this is the answer from a modo that found a fix but maybe you can confirm or adapt it in more elegant way or not :)

The issue is related to this part (not in 2.1 forum)  <link rel="next" href=... />
That part of code can be found at the line 150 of the script "index.template.php" for the default theme :

Quote// If we're viewing a topic, these should be the previous and next topics, respectively.
   if (!empty($context['current_topic']))
      echo '
   <link rel="prev" href="', $scripturl, '?topic=', $context['current_topic'], '.0;prev_next=prev" />
   <link rel="next" href="', $scripturl, '?topic=', $context['current_topic'], '.0;prev_next=next" />';

So he thinks this can be removed for good but has interrogation, maybe this can be kept for only not logged user, like this bot indexation can do their job (search engine) ? :)

What do you think and maybe you can confirm that removed or let only for no logged user will not create regression ?
For sure, when he added those 2 lines on 2.1 forum version, this issue start to appear.

Thanks ;P

shawnb61

Yes, the above works.  I have been testing that myself.

I believe this is a bug in Chrome.  In the past, the links above helped search engines deal properly with pagination, but they haven't been used for a while, so they are unnecessary.  They are not used in 2.1, which doesn't have this issue.

And their presence definitely causes issues with the latest Chromium-based browsers.  The browser generates a "silent" next page request, that is not displayed.  But SMF sees the next page request & delivers it & thus marks the page as read.

The browser is generating two GET requests, as if you hit the next > subject link.  This is from my apache access log:
127.0.0.1 - - [11/Dec/2020:13:50:26 -0800] "GET /yadayada/index.php?topic=2.0 HTTP/1.1" 200 5650
...
127.0.0.1 - - [11/Dec/2020:13:50:29 -0800] "GET /yadayada/index.php?topic=2.0;prev_next=next HTTP/1.1" 200 5442
Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp

vbgamer45

Very interesting thanks for looking into it! Should help with sever load but generally i don't think many people use those links in topics.
Community Suite for SMF - Take your forum to the next level built for SMF, Gallery,Store,Classifieds,Downloads,more!

SMFHacks.com -  Paid Modifications for SMF

Mods:
EzPortal - Portal System for SMF
SMF Gallery Pro
SMF Store SMF Classifieds Ad Seller Pro

shawnb61

Quote from: vbgamer45 on December 11, 2020, 06:35:43 PM
Very interesting thanks for looking into it! Should help with sever load but generally i don't think many people use those links in topics.

To be clear, the next/prev links remain.

These link rel attributes are at the top of the page source, and are meant to be metadata showing the relationships between pages.   Helpful to search engines, not nav buttons.
Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp

Sebastiii

Quote from: shawnb61 on December 11, 2020, 06:20:37 PM
Yes, the above works.  I have been testing that myself.
Great, thanks for confirming :)

QuoteI believe this is a bug in Chrome.  In the past, the links above helped search engines deal properly with pagination, but they haven't been used for a while, so they are unnecessary.  They are not used in 2.1, which doesn't have this issue.
So this can be removed in current 2.0 code ;D

QuoteAnd their presence definitely causes issues with the latest Chromium-based browsers.  The browser generates a "silent" next page request, that is not displayed.  But SMF sees the next page request & delivers it & thus marks the page as read.
Ok, that's good again for your explanation and confirmation, we will go this way to fix it for now :)

shawnb61

I am fairly sure this is a bug with Chromium itself, that exhibits in both Edge & Chrome.

We'll see what comes back from the Chromium team.  (They have created accounts on this site & are attempting to recreate on their end...  You can see the back & forth here: https://bugs.chromium.org/p/chromium/issues/detail?id=1158209)
Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp

Sebastiii

Quote from: shawnb61 on December 14, 2020, 09:13:01 PM
I am fairly sure this is a bug with Chromium itself, that exhibits in both Edge & Chrome.
Yes it seems so :)

QuoteWe'll see what comes back from the Chromium team.  (They have created accounts on this site & are attempting to recreate on their end...  You can see the back & forth here: https://bugs.chromium.org/p/chromium/issues/detail?id=1158209)
Big thanks for opening a bug report there, hoping for a fix :)

crash56

FWIW, I ran into this exact same issue at our forum.  I applied the fix described in Reply #21, and it did the trick.  The unread posts are behaving properly now.  Thank you, all you genius SMF gurus.  :D

prefertolurk

Just a follow up, I posted a link to this thread and the recommended fix in our bug report forum over at hxxp:nasaspaceflight.com [nonactive] and after they disabled the prefetch prev/next links everything is working as intended again! 

Thanks for your help.

Sebastiii

@prefertolurk and @crash56
For now, it's the way to go  :)

drewactual

i've seen this too.... a member brought it to my attention and it happens every time.  i haven't had any time to look into it, though.   i'm still running 2.0.15 on that forum, as i'm waiting for full release of 2.1 before i do anything else with it. 

Kindred

You do need to update to 2.0.17 if you plan to stay on 2.0.x until 2.1 is ready
Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

Sebastiii

Good there an update with a commit to master on Chromium bug report :)
I can't test right now but looking at it, it's related prefetch for the next tag :) So looks nice :)

shawnb61

The fix to the Chromium engine has been moved to production & is in the just-released version of Chrome.  I have tested it, & it looks good!

Tested on Chrome Version 87.0.4280.141 (Official Build) (64-bit).
Address the process rather than the outcome.  Then, the outcome becomes more likely.   - Fripp

Sebastiii

Thank you, @shawnb61
This is really great that you have looked into this and reported the bug on chromium bug report :)
Time to test :)

Turrican3

I am not 100% sure we're talking about the very same issue but I believe I'm seeing it with Firefox 64-bit 84.0.2 as well (Windows 10)

So I'm going to try to apply the fix suggested and see if this works.

Sebastiii

For now on Chrome build:
Version 87.0.4280.141 (Official Build) (64-bit)

And Brave build:
Version 1.18.78 Chromium: 87.0.4280.141 (Official Build) (64-bit)

It doesn't work, on https://www.simplemachines.org/
This is weird !

Sebastiii

Good news :)
On version :
Brave : Version 88.0.4324.96 (Official Build) (64-bit)
Chrome : Version 88.0.4324.104 (Official Build) (64-bit)
Edge : Version 88.0.705.50 (Official Build) (64 bits)
it's fixed on my side :)

Advertisement: