Skip to content
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

Jump to bottom

Dragging into topmost folder #1945

Closed
cyberduck opened this issue Apr 16, 2008 · 8 comments
Closed

Dragging into topmost folder #1945

cyberduck opened this issue Apr 16, 2008 · 8 comments
Assignees
@dkocher
Labels
bug fixed interface User Interface
Milestone
4.0

Comments

@cyberduck
Copy link
Collaborator

f3579a0 created the issue

The drop target area for the first folder in the list is located below the folder's row (top third of the row below) if the list isn't long enough to trigger vertical scroll bars. Instead, the folder's row targets the current directory. If the list is long enough to cause vertical scroll bars to appear it works as expected.

I'm using build 3767.
@cyberduck
Copy link
Collaborator Author

@dkocher commented

#1920 closed as duplicate.

@cyberduck
Copy link
Collaborator Author

anonymous commented

In Build 3999 the problem happens irregardless of whether or not the scrollbars are trigged. The drop area for the first list item is always in the top third or so of the item below it and requires careful positioning to drop items into that folder.

@cyberduck
Copy link
Collaborator Author

anonymous commented

This problem only seems to occur when 'Use spring-loaded folders when dragging files' is NOT switched on. Still very annoying though!
Using version 3.0.1 (3999). Haven't tested any other versions.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

#2368 closed as duplicate.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Milestone 3.2 deleted

@cyberduck
Copy link
Collaborator Author

@dkocher commented

I can no longer reproduce this in the latest nightly build.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

#5090 closed as duplicate

@cyberduck
Copy link
Collaborator Author

@dkocher commented

In 53b5a91.

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@dkocher dkocher

Labels
bug fixed interface User Interface
Projects
None yet
Milestone
4.0
Development

No branches or pull requests
2 participants
@dkocher @cyberduck