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

Selecting files by typing is not consistent with behaviour in #6710

cyberduck opened this issue Jun 5, 2012 · 1 comment


Copy link

@cyberduck cyberduck commented Jun 5, 2012

Chocolate Camera created the issue


When in a window with a list of files, selecting a file by typing its filename is not consistent with how the Finder does it:

  1. Typing a letter no file starts with, causes an alert sound. The Finder selects the alphabetically following closest file.
  2. The timeout to reset the search (i.e. interpreting that a typed letter is the first in the filename instead of the following to the previously typed) is longer than the Finder's. The Finder's seems to be 1 sec. Cyberducks seems to be around 2 sec.
  3. If more than one file starts with that letter, typing the letter again will select the following file. The Finder will not alter the current selection.

How to reproduce

  1. Open an FTP window, create a folder, enter it and create the following files:

    • AAA
    • CCC
    • CDD
    • CEE
    • DDD
  2. Type B.

  3. After 2 sec, type C.

  4. After 2 sec, type C again.

  5. After 1 sec but before 2 sec, type D.

  6. After 2 sec, type D


  1. Will cause an alert sound
  2. Will select CCC
  3. Will change selection to CDD
  4. Will keep CDD selected
  5. Will change selection to DDD

Expected results

  1. Should select CCC
  2. Works as expected
  3. Should keep CCC selected
  4. Should change selection to DDD
  5. Worked as expected.


Versión 4.2.1 (9350) on Mac OS X 10.6.8

Copy link
Collaborator Author

@cyberduck cyberduck commented Sep 10, 2013

@dkocher commented

Closing this issue as we are using the standard type ahead selection feature of the Cocoa user interface components since some time now (15e5373). The behaviour should therefore be consistent with other applications.

@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.
None yet

No branches or pull requests

2 participants