-
Notifications
You must be signed in to change notification settings - Fork 95
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
Fade out user cursor labels after five seconds of inactivity #4336
Conversation
Passing run #11351 ↗︎Details:
This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. |
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.
Generally the change looks good to me, animation behaviour seems very stable and looks nice. However updating the timestamp on the awareness state seems to cause two push requests for typing an individual character (one for the awareness, one for the step). Maybe we can combine them in some way?
We're now waiting 50ms before sending out the first push. This way the awareness update will be part of it. |
4f0b88a
to
68832c4
Compare
src/services/SyncService.js
Outdated
@@ -165,7 +162,7 @@ class SyncService { | |||
this.#sendIntervalId = null | |||
this._sendSteps(getSendable).then(resolve).catch(reject) | |||
} | |||
}, 200) | |||
}, 50) |
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.
This could have an impact on the resource demand due to increased push requests on the server. I think the PR itself should also be fine with the existing 200ms. Any reason to decrease that specific to the cursor hiding?
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.
This is a bit tricky as we change the initial waiting. Before if there was no request pending we would just send it immediately - so the 200 ms had no effect at all. Now we also delay this initial message.
I remember that 200ms are roughly what the human brain starts to notice as a delay. But that is only if one is waiting for a direct response from the UI. This will only delay the sync between different parties. So 200 ms are probably okay there as well.
I'd say we go with the 200 ms and if we notice usability issues with it we can change it to 50 ms on the initial request and 200 when another request is pending.
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.
Okay... so i gave this a try locally with 200 and noticed that the polling delay still is the main delay one notices. If I type fairly fast 200ms will result in two keystrokes getting combined in one push request. That seems totally reasonable. If this actually reduces the number of requests send - even better.
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.
Tested and works, one question regarding reducing the push interval inline
68832c4
to
ad800aa
Compare
Implementation details: * Add a custom CollaborationCursor Tiptap extension * Add CSS to fade out the cursor label after some time. * Listen for Yjs updates. - If it's a doc change by ourself, update the timestamp of own user in awareness state. - If it's a remote awareness update, add back the CSS class to the corresponding cursor. - Wait 50ms before showing the cursor in the DOM to account for cases where the cursor gets re-rendered by y-prosemirror. Fixes: #4126 Signed-off-by: Jonas <[email protected]>
ad800aa
to
7412c4e
Compare
/compile |
Funny that lint passes even though we introduced a warning. |
9bd5767
to
55e4679
Compare
/compile |
Document changes trigger awareness updates. Wait before sending them in a push request so they can be combined. Also make use of prosemirrors transactions to detect own changes instead of listening to yjs updates. Signed-off-by: Max <[email protected]>
a18ccab
to
928fe35
Compare
/compile |
/backport b7baceb,928fe3527a7467c78612e7db43fe35dead65819a to stable27 |
backport b7baceb,928fe3527a7467c78612e7db43fe35dead65819a to stable26 |
Signed-off-by: nextcloud-command <[email protected]>
I'm not sure about the backports. 27 is pretty clear to me also as this does not break any api and 28 will still be quite some time into the future. But 26 I don't know. |
I think we discussed this already and decided to backport this to stable26 as well, because it fixes an annoying usability bug. |
/backport b7baceb,928fe3527a7467c78612e7db43fe35dead65819a to stable26 |
📝 Summary
Fade out user cursor labels after inactivity.
Implementation details:
awareness state.
corresponding cursor.
where the cursor gets re-rendered by y-prosemirror.
Fixes: #4126
🏁 Checklist
npm run lint
/npm run stylelint
/composer run cs:check
)