New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"mark as read" has a ~1sec delay #2332
Comments
Yes, intended, and even more asynchronous than before
We will follow-up in #2304 instant visual feedback to users |
I'm invitating myself into this issue, sorry if it's not right solution. I've just updated to version 1.14.0 and it appears that an article does no longer disappear when marked as read. I have to refresh the page (with F5) to see the that the article has disappeared from the unread article list. Is this the expected behavior? |
@oupala This is with the |
Thank you for the explanation. I can live with this behavior until #2304 is in place. It's just the impression of unresponsiveness, but after all it's all usable as before. |
FreshRSS#2332 FreshRSS#2345 Re-introduces the instant-remove article. Batch mark-as-read only used for fast actions like scroll and keyboard shortcut for next/previous articles.
Could you please try #2349 ? |
Applied to dev branch and works like a charm for me. Thank you! |
Thanks for the quick feedback :-) |
FreshRSS#2332 FreshRSS#2345 Re-introduces the instant-remove article. Batch mark-as-read only used for fast actions like scroll and keyboard shortcut for next/previous articles.
FreshRSS#2332 FreshRSS#2345 Re-introduces the instant-remove article. Batch mark-as-read only used for fast actions like scroll and keyboard shortcut for next/previous articles.
After updating to 1.14.0 marking articles as read has a delay of about 1 second until the "eye" icon and the headline turns grey. The other way around, marking as unread, has immediate visual feedback.
Maybe marking as read is not handled asynchronously anymore? Maybe intended?
The text was updated successfully, but these errors were encountered: