While you're here, please consider supporting GamingOnLinux on:
Reward Tiers: Patreon. Plain Donations: PayPal.
This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!
You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Reward Tiers: Patreon. Plain Donations: PayPal.
This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!
You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register
-
Ubuntu 24.04 LTS (Noble Numbat) is now available
- tpau -
Factorio devs detail their 'Linux adventures' in a new …
- Ehvis -
SteamVR Beta gets Linux fixes, plus Beta updates for De…
- based -
Ubuntu 24.04 LTS (Noble Numbat) is now available
- Highball -
SteamVR Beta gets Linux fixes, plus Beta updates for De…
- ElectricPrism - > See more comments
Latest Forum Posts
- Free Steam Keys!
- robvv - Company of Heroes 2 Benchmark
- Vortex_Acherontic - New Desktop Screenshot Thread
- Owltech - Hello to all
- JordanBurton - Introduce Yourself!
- goule - See more posts
View PC info
If I click 'reload', or load the page again in a new tab, the filter is applied correctly. So maybe somehow cookie related?
In case it matters, browser is Vivaldi (snapshot, currently 2.5.1497.4).
Sounds more like it might be a cache issue in Vivaldi possibly.
View PC info
That's a screenshot from when I first loaded the page today (good I made one...)
I had not loaded the page (with those article) earlier, so it can hardly be a cache issue. And as you can see, it is not even directly visible on the page, I had to scroll down several articles before that one was shown/loaded. But the icon in the top shows that I am logged in.
Could it be that verifying login status takes too long first time, and the article content is requested in anonymous state or something? (sorry for blind guessing...).
No, just not how it works.
If it happens again, could you check the networking panels and so on to make sure it's not grabbing some kind of page cache? I've tested and re-tested and the only time I've seen it is on Android, where i closed everything and loaded the browser and it seemed to save the page state or something as refreshing it then showed articles removed from a tag. Can't reproduce on desktop.
View PC info
I had seen it before (twice), also on a different computer (same browser though). So after the third time I thought it's worth a bug report. But if I'm the only one seeing it don't bother....
View PC info
Funny reproduction method: Add tags on my phone, open firefox on desktop (GOL is my own homepage :P) and boom it doesn't happen until a refresh.
Bug confirmed.
Essentially, I was looping over the blocked list and then checking the user session. The issue comes up, since the session checker does the auto-login, so the blocked list would be empty until the refresh. Had the function calls in the wrong order.
Thank you for helping to make GOL better by reporting a bug!