Open christianglodt opened 2 months ago
I maybe see this issue, or something related. When I "Mark as read" there are a few articles that stay in the list, I believe the ones that I have clicked on to read fully. They are still marked read, but they don't disappear like the other articles. This is new behavior the last week-ish, or so.
This issue is old of years. It is a duplicate of another already described issue.
@garret can you share the link here?
647
not same issue. this issue is mark new items as read while user click mark all read button. #647 is mark read due to auto mark above as read.
Yes, but isn't the 'automarking as read' just like an automatic tapping on the 'mark as read' button? So, it doesn't really matter since the result is the same? That was my point 🙃
the solution is different.
Describe the bug I use FeedMe with a miniflux server via the Fever protocol. I read the "All Items" feed, and when I reach the end, I tap the "Mark all read" floating-action-button. When I do this, the list goes back to the top, and all items are marked as read (with a non-bold title). However, sometimes, I then see some new articles at the top of the list, which I've not seen before, and which are already marked as read. This does not always happen.
I have a theory about a possible cause. Could it be that FeedMe did a time-based auto sync in the background while I was looking at my feeds, and that "Mark all read" also marks new items from this auto sync as read?
I think the "Mark all read" button should only mark those items that are in the currently shown list, not any new ones from a sync operation that are not currently shown.
To Reproduce I don't have a tested way to reproduce this problem. It might be possible like this:
Expected behavior I would expect any new items that are obtained by background sync to remain unread. I would expect the "Mark all read" button to only affect those articles that are in the list that is currently shown.
Device info