-
Notifications
You must be signed in to change notification settings - Fork 344
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
Refresh keyboard shortcut issues in 2.19 #1405
Comments
Thanks for reporting. I wonder if this is the same as #1388. Would you be able to test the latest snapshot? |
Just updated to your indicated snapshot - I'll report back if I notice the issue again. Thanks! |
OK, still experiencing this issue. Might have narrowed down the steps to reproduce. I have a list of tagged unread items that's currently 51 items long. Refresh the page, click on the tag, scroll to the bottom - triggers more items to load - open an item and then press R. Not a lot happens! Hope this helps. |
Actually I was wrong, it seems to add the 51st item over and over with each press of 'R' |
I'm using 2.19 too and the refresh shortcut adds and adds the existing items. They just repeat. I didn't have this behaviour on 2.18 |
I am not able to reproduce. It might have actually been fixed by #1458. Could you please check the latest snapshot? Edit: Never mind, that only fixed issue that appeared in 2.20 snapshot. Will try to debug it some more during the week. |
I have tried the latest snapshot (283ceaa) but I still have the issue. |
I'm used to browsing my feeds with keyboard shortcuts, using tags to read a specific subject, displaying unread items.
As I read down the list, I use 'J' to navigate to each item in turn, 'V' to open items and occasionally I press 'R' to clean up the list.
On 2.18, 'R' happily refreshed the feed, hiding the read items and displaying any newly fetched ones.
On 2.19, this works intermittently, sometimes working, but often causing some kind of reload (in Chrome 109.0.5414.120 it shows the "Waiting for URL...." at the bottom of the window), but ultimately doing nothing to the list; unread items remain towards the bottom, read items remain at the top. Seems to happen more frequently with longer (>50) lists of unread items.
The text was updated successfully, but these errors were encountered: