-
Notifications
You must be signed in to change notification settings - Fork 42
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
Fix scroll to bottom issue in #61. #685
Conversation
It's important to distinguish between:
By way of comparison, Slack will always scroll to the bottom if you send something, but it will keep your scroll position if another user sends something. In that case, it will show a "jump to new message" bar at the top. That "jump to new message" bar is important -- it would be problematic to keep the scroll position without showing some indicator that new messages from a source have arrived. Since we can safely assume that real-time interactions are pretty rare, for the beta, it's IMO fine to just always jump to the bottom of the conversation view in both cases for now. Nina, please jump in if you disagree. |
@eloquence thanks for the feedback. I imagined you'd reply with something like you did (but I didn't want to just start changing UI behaviour without flagging things and getting some feedback). AFAICT the behaviour can be encapsulated in this sentence: do not scroll to the bottom unless the new message is from the logged in journalist. The scroll to new message (a la Slack) is perhaps a new feature to be explored from a UX PoV before you let me get my grubby hands on it. ;-) |
OK... I've been spending some more time looking into this thinking I could enhance the current state of this PR (which has the behaviour described by @eloquence -- i.e. scroll to bottom for all messages), so that only messages from the journalist cause the scroll to bottom. It turns out that every time a new message is sent or received the conversation is cleared and then re-added to the widget (see the However, as it stands this PR is ready to merge, but I wanted to flag such odd behaviour found while investigating this issue during today. |
To be clear, I think without a way to jump to new messages, that could be very confusing -- you might find yourself looking at an old message and not notice that a new one has arrived from the source. So for now I think the behavior implemented in this PR is in fact preferable, until such a time we have a UX design for highlighting new messages that could be implemented alongside further enhancements. |
👍 |
Cross-referencing the related #635 in case it's still an issue. |
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 resolves #635
However it also introduces a regression, see: #144. When the user clicks "DOWNLOAD", they might also want to open, print, or export it. This should be fixed before merging.
It is also a regression to scroll to the bottom when the user has the conversation loaded and is positioned somewhere in the middle of a thread (I will try to find a relevant ticket with background info). It could be a long conversation or a long single message from a source that they are in the middle of (which is why it's the conversation that is being actively viewed in the first place). Moving the user mid-view/read is something we've discussed in design meetings so others may want to chime in.
If you mean "scroll to the bottom if a message arrives during that time", as noted above, that's IMO preferable to potentially missing the new message entirely. The ideal long term solution here would be to have a Slack-like "Jump to new message" appear without scrolling the conversation view (while always scrolling it for journalist-initiated replies), but given that real-time conversations are the exception in SecureDrop, I think this is an acceptable solution for the beta. Happy to discuss further, of course. If you're describing a different "scroll to the bottom" scenario, could you elaborate? |
I recorded the a video to clarify the two regressions I mentioned above (a) clicking on the "Download" button now auto-scrolls you to the bottom of the conversation and you will have to scroll back up to open it, and (b) when a new message comes in (this will happen during a background sync) for the conversation that you are in the middle of reading the client auto-scroll you to the bottom of the conversation and you will have to scroll back up to open it. The design decision we made at the end of last year was to only "stick" to the bottom of the conversation if the user is already at the bottom of the conversation or if the user loads a new conversation by clicking on a source. Note: I click on the refresh icon instead of waiting for a background sync in this recording for demo purposes |
That's clearly broken.
IMO that's the right behavior for now, until we have a new message indicator. It's arguably worse if the new message comes in and the user never sees it because they were scrolled up. In any event, if we change this further, then we should still make sure that the user's own replies always trigger a scroll. |
#187 is a high-priority issue to show users when new messages come in and indicating it per source in the source list. I think changing the code to auto-scroll to the bottom when a new message comes in while the user is viewing the conversation in a different location is unnecessary given that this is not the design we're working towards. I believe the scope of this PR is to (a) resolve #635 which is, as you pointed out, making sure that when a user sends a reply we don't scroll to the top of the conversation, and (b) make sure we continue to autoscroll to the bottom when new messages come in only if the user is already at the bottom of the conversation view-- we already have code for this that deeplow added. |
That's fair; my main point is that I don't think its a huge deal either way at this point and there are downsides to this approach in the absence of newness indicators, so we should go with what's quickest.
We should IMO autoscroll if they're not at the bottom, but sending a reply. That's at least how Slack does it, and pretty common messaging app behavior. |
Morning folks. My summary of the story so far... From my PoV everything @creviera says makes sense, except there were bugs such that the scrolling didn't work in the way described (i.e. the scrolling was jumping around -- the problem I was assigned to fix). Yet my work (just scroll to the bottom) has introduced a regression. Also, @eloquence has made the point that something must be done quickly so this aspect of the client is broken for release. So what to do..? ;-) To synthesis all the suggestions we ger:
For the sake of "something must be done", I'll fix up this PR to reflect the behaviour in the two points mentioned above. At least this addresses both aspects of the UX ("don't scroll, I'm doing something" and "I expect to see my new message"). This will mean the UI is working without bugs and consistently. I expect this behaviour will be re-visited as we work out what more we may need to do given actual user feedback and the potential for readjustment and refinement (for instance a "scroll to bottom" button). My personal take is that, for now, "it'll do" and we can refine in future. I hope this makes sense. |
OK... this PR should be dropped because the changes made in #688 make the solution possible. The technical explanation follows:
Phew..! Apologies for dumping "War and Peace" length explanations on tickets, but I also don't want you to have to go through the unpicking of code I've just had to go through. Brain share... it's a thing.! ;-) |
Fix freedomofpress#61 to supercede freedomofpress#685. Make on_reply_sent work properly without duplicate entries.
Description
Fixes #61.
I've undone some changes that were applied to the original code which ensured that when new messages were added the pane would scroll to the bottom. I'm unsure why this code would have been added. AFAICT, when a new message is added to the pane, you should be able to see it!
Before merging, I'd like to explore what problems I may be re-introducing by removing this code (and associated test). The comment in the test appears to suggest that the code was added to avoid scrolling if the journalist was reading an older message. I feel these requirements are mutually exclusive, IYSWIM, so some sort of UX decision / discussion should probably happen (pinging @ninavizz).
Test Plan
This is removal of code and an associated unit test. Further UX discussion is required and I expect further revisions to the code to reflect the outcome of such discussions.
Checklist
If these changes modify code paths involving cryptography, the opening of files in VMs or network (via the RPC service) traffic, Qubes testing in the staging environment is required. For fine tuning of the graphical user interface, testing in any environment in Qubes is required. Please check as applicable: