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

Type selection in browser takes too long stopping early #4170

Closed
cyberduck opened this issue Jan 29, 2010 · 23 comments
Closed

Type selection in browser takes too long stopping early #4170

cyberduck opened this issue Jan 29, 2010 · 23 comments
Assignees
Milestone

Comments

@cyberduck
Copy link
Collaborator

1b3fb53 created the issue

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

@cyberduck
Copy link
Collaborator Author

@ylangisc commented

As of 15e5373 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.

@cyberduck
Copy link
Collaborator Author

@ylangisc commented

Closed #4383 as duplicate.

@cyberduck
Copy link
Collaborator Author

ecbebe0 commented

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.

@cyberduck
Copy link
Collaborator Author

ecbebe0 commented

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.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

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

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Reopen due to #5752.

@cyberduck
Copy link
Collaborator Author

ecbebe0 commented

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.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:9 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.

@cyberduck
Copy link
Collaborator Author

ecbebe0 commented

Replying to [comment:10 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?

@cyberduck
Copy link
Collaborator Author

ecbebe0 commented

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?

@cyberduck
Copy link
Collaborator Author

ecbebe0 commented

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.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

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.

@cyberduck
Copy link
Collaborator Author

ecbebe0 commented

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.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Replying to [comment:18 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?

@cyberduck
Copy link
Collaborator Author

ecbebe0 commented

Yes

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Fixed icon cache access in 934ec23.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

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.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Possible optimization in 6288648 to only match the filename column.

@cyberduck
Copy link
Collaborator Author

ecbebe0 commented

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

@cyberduck
Copy link
Collaborator Author

209ab90 commented

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.

@cyberduck
Copy link
Collaborator Author

209ab90 commented

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.

@cyberduck
Copy link
Collaborator Author

ecbebe0 commented

Same here on 10.9.2 and 4.4.4.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

Possibly fixed with #9970.

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

No branches or pull requests

2 participants