#2905 closed Bug report (rejected)
stop scrolling in message log
Reported by: | pnoeric | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | FileZilla Client |
Keywords: | Cc: | pnoeric | |
Component version: | Operating system type: | ||
Operating system version: | Windows |
Description (last modified by )
Hi, when a file transfer is happening, if I scroll up in the log, it keeps moving and I can't really read it.
My sugestion is that as soon as the log isn't at the very bottom, scrolling is frozen (though it continues to fill) so I can look back at the log and read entries while the transfer is still proceeding.
Change History (5)
comment:1 by , 14 years ago
comment:2 by , 12 years ago
Operating system version: | → Windows |
---|---|
Type: | Feature request → Bug report |
comment:3 by , 8 years ago
Description: | modified (diff) |
---|---|
Resolution: | → rejected |
Status: | new → closed |
The log buffer is limited in size and content will disappear if new lines are added. Stop queue processing if you need time to read old messages.
comment:4 by , 6 years ago
This is still a very frustrating behaviour. And whilst the log buffer may be limited in size, I wonder how large those limits are and whether that is enough of a reason to not provide the same experience/behaviour for the Windows clients as the Linux clients.
If this change is still not going to happen, maybe the Message Log pane on the Windows client should not be scrollable when the queue is being processed, as the current situation allows a user to try and scroll back through their history whilst new lines are being added to that pane, only to snap the user straight back to the bottom when that next line is appended. In short, the behaviour feels broken.
comment:5 by , 2 months ago
Agreed. 17 years later and this still feels broken. Other applications handle such scrolling without issue: if the user is at the bottom, continue to scroll, otherwise lock in place. I do not understand why this was rejected; it seems a very reasonable request. Please reconsider.
This ticket's suggested behavior appears to have been the current behavior on Unix-like systems for some time (I tested it with filezilla 3.3.3-1ubuntu1 as provided by my Ubuntu 10.10 Maverick Meerkat amd64 system). But this issue has still not been addressed in Windows (with version 3.3.5.1).
Given that the less desirable behavior occurs only on Windows, I would suggest that this ticket would now be better classified as a bug report, rather than a feature request. However, I will leave that to others to decide.