#4170 closed enhancement (worksforme)
Type selection in browser takes too long stopping early
Reported by: | jg@… | Owned by: | dkocher |
---|---|---|---|
Priority: | normal | Milestone: | 6.3.1 |
Component: | interface | Version: | 3.4.1 |
Severity: | normal | Keywords: | |
Cc: | Architecture: | ||
Platform: | Mac OS X 10.6 |
Description
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.
Attachments (2)
Change History (33)
comment:1 Changed on Feb 5, 2010 at 8:32:27 AM by yla
- Component changed from core to interface
- Milestone set to 3.4.2
comment:2 Changed on Mar 31, 2010 at 2:06:53 PM by dkocher
- Milestone 3.4.2 deleted
- Summary changed from Can no longer type to find file to Type selection in browser takes too long stopping early
comment:3 Changed on Apr 9, 2010 at 1:54:06 PM by yla
- Platform set to Mac OS X 10.6
Closed #4383 as duplicate.
comment:4 Changed on Oct 20, 2010 at 1:37:23 PM by 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.
comment:5 Changed on Oct 27, 2010 at 1:54:54 PM by 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.
comment:6 Changed on Nov 20, 2010 at 11:21:12 AM by dkocher
- Milestone set to 4.0
- Resolution set to fixed
- Status changed from new to closed
This should be resolved as of r7637. Please reopen if still an issue in the latest nightly build.
comment:7 Changed on Mar 10, 2011 at 6:04:46 PM by dkocher
- Milestone changed from 3.8 to 4.1
- Resolution fixed deleted
- Status changed from closed to reopened
Reopen due to #5752.
comment:8 Changed on Jun 29, 2011 at 8:38:57 PM by dkocher
- Milestone 4.1 deleted
comment:9 follow-up: ↓ 10 Changed on Jun 30, 2011 at 9:50:05 PM by 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.
comment:10 in reply to: ↑ 9 ; follow-up: ↓ 11 Changed on Jul 1, 2011 at 5:55:31 AM by 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.
comment:11 in reply to: ↑ 10 Changed on Jul 1, 2011 at 4:38:29 PM by 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?
comment:12 Changed on Dec 6, 2011 at 7:11:56 AM by 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?
comment:13 Changed on Nov 26, 2012 at 6:37:15 PM by dkocher
- Milestone set to 4.2.2
- Resolution set to worksforme
- Status changed from reopened to closed
comment:14 Changed on Nov 26, 2012 at 8:16:50 PM by udittmer
- Resolution worksforme deleted
- Status changed from closed to reopened
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.
comment:15 Changed on Dec 17, 2012 at 10:22:55 AM by dkocher
- Milestone 4.2.2 deleted
- Status changed from reopened to new
comment:16 Changed on Aug 18, 2013 at 3:29:57 PM by dkocher
- Milestone set to 4.4
comment:17 Changed on Aug 21, 2013 at 12:39:57 PM by dkocher
- Resolution set to worksforme
- Status changed from new to closed
comment:18 follow-up: ↓ 19 Changed on Sep 2, 2013 at 9:45:53 PM by udittmer
- Resolution worksforme deleted
- Status changed from closed to reopened
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.
comment:19 in reply to: ↑ 18 Changed on Sep 8, 2013 at 9:43:50 PM by 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?
comment:20 Changed on Sep 9, 2013 at 7:23:44 AM by udittmer
Yes
comment:21 Changed on Sep 10, 2013 at 10:28:06 AM by dkocher
Fixed icon cache access in r12789.
comment:22 Changed on Sep 11, 2013 at 10:17:53 AM by dkocher
- Resolution set to wontfix
- Status changed from reopened to closed
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.
comment:23 Changed on Sep 11, 2013 at 1:56:35 PM by dkocher
Possible optimization in r12844 to only match the filename column.
comment:24 Changed on Sep 22, 2013 at 10:52:42 PM by 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 :-)
comment:25 Changed on Apr 15, 2014 at 7:35:01 PM by 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.
Changed on Apr 15, 2014 at 8:13:19 PM by 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.
comment:26 Changed on Apr 15, 2014 at 8:16:26 PM by ian cook
To reproduce:
- Extract t.zip to a S/FTP server.
- Navigate to location in Cyberduck.
- Click the first line of files.
- 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.
comment:27 Changed on Apr 16, 2014 at 10:02:59 AM by dkocher
- Milestone changed from 4.4 to 4.5
- Resolution wontfix deleted
- Status changed from closed to reopened
comment:28 Changed on Jun 2, 2014 at 3:22:49 PM by dkocher
- Milestone 4.5 deleted
comment:29 Changed on Jun 2, 2014 at 4:58:39 PM by udittmer
Same here on 10.9.2 and 4.4.4.
comment:30 Changed on Apr 5, 2016 at 2:15:14 PM by dkocher
- Type changed from defect to enhancement
comment:31 Changed on Nov 27, 2017 at 3:46:04 PM by dkocher
- Milestone set to 6.3.1
- Resolution set to worksforme
- Status changed from reopened to closed
Possibly fixed with #9970.
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.