Opened 17 years ago

Closed 8 years ago

Last modified 2 months ago

#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 Tim Kosse)

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 Eliah Kagan, 14 years ago

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.

comment:2 by Alexander Schuch, 12 years ago

Operating system version: Windows
Type: Feature requestBug report

comment:3 by Tim Kosse, 8 years ago

Description: modified (diff)
Resolution: rejected
Status: newclosed

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 Luke, 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 Jinx Dojo, 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.

Note: See TracTickets for help on using tickets.