Item marked read in another feed

Describe the problem you’re having:
Item gets marked as read in a feed where the action wasn’t executed.
If possible include steps to reproduce the problem:

  1. In a feed that had one item, I scroll down and mark it read.
  2. Switch to another feed
  3. The first item in the newly opened feed is marked as read, though there was scrolling yet.

tt-rss version (including git commit id):
Just updated

Platform (i.e. Linux distro, PHP, PostgreSQL, etc) versions:

Please provide any additional information below:
I’ll add more info as I test it more…

I’m going to guess you’re using MySQL without InnoDB; if that’s the case you should re-install and set things up properly (while you’re at it, use PostgreSQL).

How do you know the article in the other feed was not marked as read already (i.e. what makes you think your marking an article in the first feed affected the article in the second)?

You should check for filters and plugins that may be modifying the unread state.

Anyway, you didn’t complete the form properly so no one here knows anything about your setup. Go back and answer the questions properly.

this could also be related to UI not scrolling the headlines properly to top when switching feeds but this has been fixed a while ago, so idk. it’s hard to figure out anything from his post.

MySQL with InnoDB.
Set up like 7 years ago. Maybe back then it was the way to go?
Good idea to migrate to Postgre though.

Why I think those things?
I opened the new feed, didn’t scroll a pixel, all items are unread and the first one is being marked read right in front of my eyes, without interaction from my side.
It looks to me as if marking read of the old item took ~300ms longer and it somehow affects the new one. As if the action was “mark 1st item in the current feed read” but in the meantime I was in another feed.

I don’t see how filters and plugins could do this. If it was done by those, it wouldn’t be shown at page load, since only unread items are loaded.

Open the web inspector, select the Network tab, then repeat the steps that cause the issue. Post the XHR requests here (please remove any identifiable information like domains, tokens, etc.; if you’re not sure just send the info as a private message).

this is frontend-related then, what browser are you using? try incognito mode etc.

also you can try recording a short screencast of this happening with browser console open.

items are marked as read in batches but they shouldn’t affect items with different article IDs even if you switch feeds around.

Since I’m using tt-rss on desktop and mobile Chrome, I was confused first, so I rechecked this.

When I test this in Mac Chrome, new feed loading seems to wait for what is being done in the background first, blocking the load until that is done
-> problem can not happen there

I can repro this only in iOS Chrome. I remember you guys are not supporting mobile browsers, so I guess we’ll just leave this bugreport as is.

Let me know if I can do anything else here though.
Thanks for your input in this ticket.

there’s no ios chrome, it’s just safari with google UI on top of it.

safari engine (webkit) is absolutely horrible. i tried to port some stuff to it (because my wife owned an ipad at the time) and it was MSIE-tier bad at needing all sorts of polyfills and stuff. i pity those who have to develop for it.

i don’t support anything apple because i simply can’t.

Sorry for being off-topic, but…

For awhile mobile Safari was kind of nice, but having used Apple products for a long time (not any more, but for over a decade when I was using their stuff) they have this habit of releasing something awesome then never touching it for years. Whether that’s mobile Safari, the Mac Pro, laptops, etc.

Even with iPadOS they say it’s a “desktop class browser” all they’re doing is stuff similar to what Microsoft did under Ballmer: Faking user agent strings, using heuristics to change the behavior of sites (hover events, etc.).