Type selection in browser takes too long stopping early

[jg@…]

I used to be able to just start typing the name of the file or directory, but since upgrading to 3.4.1 (5780)/5780, sometimes it works and sometimes it just plays an error sound. I haven't figured out exact steps to reproduce, but it seems to happen more than half the time for me.

[yla]

As of r5645 the implementation has been changed to the built-in type ahead selection available in Mac OS X v10.5 (and later). This mostly happens with big listings. The Console log says

2/5/10 9:09:12 AM Cyberduck[2707] Type selection took over 1.000 seconds. Stopping early....

Need to dig further into this.

[yla]

Closed #4383 as duplicate.

[udittmer]

Is there any chance that this gets fixed soon, or reverted back to use the previous code? It's really a big step back in usability. And it's not just big listings - sometimes even with just dozens of files in a directory. And it happens on OS X 10.5 as well.

[udittmer]

Or maybe the number of seconds until timeout could be made a preference setting, so that users who deal with lengthy listings are once again able to use this feature.

[dkocher]

This should be resolved as of r7637. Please reopen if still an issue in the latest ​nightly build.

[dkocher]

Reopen due to #5752.

[udittmer]

This is very disappointing. From the initial comment I gather that code is (or was) available to fix this; but it is not being applied for some unknown reason. As someone who registered CyberDuck, seeing 18 months old bugs not getting fixed despite the appearance of a fix being readily available just sucks.

[dkocher]

Replying to udittmer:

This is very disappointing. From the initial comment I gather that code is (or was) available to fix this; but it is not being applied for some unknown reason. As someone who registered CyberDuck, seeing 18 months old bugs not getting fixed despite the appearance of a fix being readily available just sucks.

The issue is not as trivial as it might seem. With the patches referenced above performance was improved but apparently not enough for some configurations.

[udittmer]

Replying to dkocher:

The issue is not as trivial as it might seem. With the patches referenced above performance was improved but apparently not enough for some configurations.

The first comment implies that the code that was working correctly was replaced by code that has problems. Would there be more to fixing the issue than reinstating the old code?

[udittmer]

It's been a few months without a reply, so I thought I'd ask again: Is there any prospect of the original code being reinstated, maybe as a user-selectable option?

[udittmer]

No, nothing has changed - it doesn't work. Still getting the following error in the system.log:

Nov 26 21:13:50 e178138067 Cyberduck[47453]: Type selection took over 1.000 seconds. Stopping early....

How would you like me to provide you with a test case? I'd be happy to run a debug version that produces whatever output you need to track this down.

[dkocher]

Please update to the latest ​snapshot build available of 4.4 and let me know if this is still an issue or has been resolved.

[udittmer]

Nothing has changed as far as I can tell:

Sep  2 23:39:48 e178159170 Cyberduck[1793]: Type selection took over 1.000 seconds. Stopping early....

Selection does work sometimes, but more often than not, it doesn't. I can only state again that I'd be happy to run a debug version that produces whatever output might help you debug this.

This was using Cyberduck 4.4 build 12661.

[dkocher]

Replying to udittmer:

Nothing has changed as far as I can tell:

Sep  2 23:39:48 e178159170 Cyberduck[1793]: Type selection took over 1.000 seconds. Stopping early....

Selection does work sometimes, but more often than not, it doesn't. I can only state again that I'd be happy to run a debug version that produces whatever output might help you debug this.

This was using Cyberduck 4.4 build 12661.

Is this still on OS X 10.6?

[udittmer]

Yes

[dkocher]

Fixed icon cache access in r12789.

[dkocher]

Please (again) test the latest snapshot build which has a generic regression fix to optimize table cell rendering. Sorry this issue is dragging on, but as this is not reproducible on later OS X versions (because the table view widgets have seen performance optimizations) I have little motivation to further optimize. Also, there is little I could do as the performance constraint depends on the number of method call the underlying OS X framework that implements type selection issues to our delegate.

[dkocher]

Possible optimization in r12844 to only match the filename column.

[udittmer]

No, that doesn't work either - but thanks for trying.

I understand the issue about not being able to support old OS X versions. The thing that irked me -and which gave me hope that a fix might be easy- was the very first comment in this thread, where you said that the old, fast matching code had been replaced by some Apple API that was slower. So I had a hope that the old code could simply be restored. I guess the time for that has passed by now. But once I upgrade to a newer OS X version and find that the matching still doesn't work I'll be back complaining some more :-)

[ian cook]

I'm seeing this exact problem using Cyberduck 4.4.3 (14140) and Mac OSX Mavericks 10.9.2. I get the same error in the console log.

The hardware is a 2013 2.6GHz MBP Retina laptop. I'm about as maxed out as it's going to get for performance and latest updates, yet I still see this issue, which happens at the most maddening time, when you need to jump down a loooooong list of files.

The directory that I reliably encounter this problem with contains 1800 files and folders.

I would be glad to put together a test case for you to reproduce this issue.

[ian cook]

screenshot of what happens after pressing "z"

[ian cook]

testcase archive of ~1800 empty files that show the error. i've kept the original names just in case the distribution of first letters was a cause.

[ian cook]

To reproduce:

1. Extract t.zip to a S/FTP server.
2. Navigate to location in Cyberduck.
3. Click the first line of files.
4. Press "z" to jump to the end of the list.

What I expect to happen:

I jump to a file starting with Z.

What really happens:

I stay at the originally selected line. An error message appears in the OS Console.

[udittmer]

Same here on 10.9.2 and 4.4.4.

[dkocher]

Possibly fixed with #9970.