Cyberduck Mountain Duck CLI

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

Screen Shot 2014-04-15 at 1.09.00 PM.png (2.0 MB) - added by ian cook on Apr 15, 2014 at 8:12:09 PM.
screenshot of what happens after pressing "z"
t.zip (331.4 KB) - added by ian cook on Apr 15, 2014 at 8:13:19 PM.
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.

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

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.

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.

Last edited on Oct 20, 2010 at 1:38:00 PM by udittmer (previous) (diff)

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: 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: 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?

Last edited on Dec 6, 2011 at 7:12:23 AM by udittmer (previous) (diff)

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.

Last edited on Apr 15, 2013 at 9:30:17 AM by dkocher (previous) (diff)

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

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.

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: 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.

Last edited on Sep 8, 2013 at 9:43:20 PM by dkocher (previous) (diff)

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:12:09 PM by ian cook

screenshot of what happens after pressing "z"

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:

  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.

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.

Note: See TracTickets for help on using tickets.
swiss made software