-
-
Notifications
You must be signed in to change notification settings - Fork 7.1k
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
Add option to disable real-time updates in web UI #9984
Conversation
27af01f
to
f885f4e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm afraid this will lead to inconsistent behavior with non-websocket updates (TIMELINE_EXPAND_SUCCESS
, NOTIFICATIONS_EXPAND_SUCCESS
), and it doesn't set the “unread” flag nor does it clean up old toots (the 40 items limit).
Furthermore, while it should reduce CPU and RAM usage, and avoid some of the “timeline jump” issues, it will fail to eliminate those coming from preview cards appearing, those coming from Content Warnings being unfolded, and will move the others to the time of scrolling.
The goal of this PR is not eliminating some code-related issues, but simply resolving a long-standing user request. |
I have added cleaning up of old toots and the unread flag. I can't progress on the expand behaviour. It doesn't help that the polling fallback is indistinguishable from first load or returning to a column after leaving it. It also does these ID comparisons and gap handling which are very finnicky. I suggest we merge the feature as it is, so that it works with streaming, and then fix the polling behaviour separately. |
Those changes looks good to me, but I'm still uncomfortable with the polling fallback, which might break everything at the slightest connectivity issue… |
4467109
to
b06f5be
Compare
I have made it work with polling updates and even disconnects. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition to the id comparison thing, there is the fact that disabling the setting will push new toots below the possibly-pending ones. Disabling the setting should probably insert the pending toots right away.
Something seems to also be preventing loading older toots when switching back and forth between modes, but it appears to be working in both modes as long as no switching is involved.
Finally, this should be extended to list timelines as well.
Turns out managing the setting for lists and hashtags and the fact that you can have multiple copies of the same timeline pinned as columns is not trivial at all, and frankly, having to toggle the setting for each and every context might be an anti-feature so how about I make it a single global setting instead |
b06f5be
to
61ab0f5
Compare
61ab0f5
to
0f0319d
Compare
0f0319d
to
8b9dedb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The name “Slow mode” really doesn't make it obvious what it does. We should find a better name or at least have a useful hint string. I'm not completely sure about having it as a list item that looks like the usual gaps and filtered items either, I wonder if it could make sense to have it in the column header instead?
Other than that, looks good to me!
8b9dedb
to
b3cebd9
Compare
Hi, I am a new user of mastodon and wanted to give some feedback on this topic regarding it's usability. Current default is automatic pushing of messages into the timeline and moving already present messages out of the visible area. I want to point out that as a user the intention is in most cases that he wants to take a look at the messages in the local timeline to explore what is interesting. However the default setting prevents exactly this by repeatedly interrupting the reading flow. Also it makes the webapp feel clunky that it is necessary to manually enable slow mode for basically the most common use case. I do understand the the want to flex/see how many messages are being pushed on a server but I feel this is usually interesting only to developers and the important use case may be in the blind spot of a developer. My suggestion is please enable slow mode by default to correspond with the most sensible use case. |
Fix #9031
Fix #7913