-
Notifications
You must be signed in to change notification settings - Fork 286
Freeze on "Open With..." action #2020
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
Comments
Do you have anything in your catalog that might be an alias to a folder on an unreachable network drive? |
I doubt it, but that's a good thought. I went through all of the catalogs, disabled each of them per major group (i.e.: Applications, Plugins, System, etc.) and ran a "Catalog Rescan" after each. Same result. The only slight difference is the Actions popup appears (with "Open" at the top and "Open With..." just below). But it's still frozen. I don't know why that changed. I updated to 10.10.2 yesterday as well. |
Does this still happen with Quicksilver 1.3.4? |
I don't know. Sometime shortly after this post I reverted to OS 10.9.5 and QS 1.0.0. I've been hessitant to update since :-) You think 1.3.4 (or some other earlier version) resolved this? |
If it was a network drive, yes. Otherwise, I’m not sure, but a lot has changed so it might be worth a look. |
I just upgraded to 1.3.4 (4016). Same result.
Some other, hopefully useful, info:
Here are a "Sample" and "Open Files & Ports" from Activity Monitor, taken while QS was frozen: I haven't deleted any preferences yet in case there are still some other steps to diagnose this. Thanks for checking in on this so far after I initially reported it! |
Just found that the same type of freeze happens with the actions:
"Open URL With..." is ok. As a result I have "Open with...", "Copy to...", and "Move to..." disabled. QS no longer crashes when those actions are called on purpose (muscle memory) or incidently. QS is also now ~30% less valuable ;-) I assume those three actions are all using the same lower level code that's causing the crash. Which fits since they all trigger the third pane that takes a path as input. |
I have the same issue here. However, when I remove the ~/Desktop folder from the catalog, it works. Hopefully that helps. |
Hi, tl;dr:
@mccoys: It did! Given your success after removing the Desktop from the catalog, I took the opportunity to start from scratch and try to see if I could isolate the problem to something in the catalog. Removing the Desktop didn't work for me. I wanted to go extreme, so I created a new user, setup QS and tested. Problem GONE. So the issue is definitely not tied to QS's codebase. So I went back to my main account and started to divide-and-conquer my way through my catalog. Long story short I found the culprits: 2x aliases to .webloc files. Here's where things get weird. I assumed something must have gotten corrupted with those files and that's why it was giving QS trouble. I double clicked on the aliases in the Finder and they work! It's still linked to the originals and the URLs open in the default browser. I figure they must not be broken enough to give the Finder a problem, but they must be broken enough to give QS a problem. So I went to the URLs in Safari, created NEW .webloc files in a different folder (which I added to my QS "Custom" catalog) and created aliases to them. Result: QS Crashed! Weird right? Then I tried going back into my test User Account, creating the .webloc's, making aliases, testing QS. Result: QS Crashed!! Just to make sure I wasn't going crazy, I excluded one from the QS catalog and QS still crashes (expected). I excluded the next and QS no longer crashed (expected). IOW: The same URLs are responsible for crashing QS in two different users on the same machine. (Another thing: I have plenty of .webloc and aliases to .webloc files in the QS catalog. There are even others in the same parent folder that's in my "Custom" catalog entry. None of them expose the bug.) Observations:
FOUND!As I was proofreading this post, I thought of another test. I had a feeling this has something to do with that
It would seem that even though the Finder converts the Still Unknown:
@mccoys: If you have the time, could you divide-and-conquer through the contents of your "Desktop" folder entry in the QS catalog, to see if you can find the culprit file in your case? It would be really helpful if we could figure out the commonality between the files that are giving QS a hard time. If I'm right about the fyi: If anyone is going to test this by adding and removing crash-inducing files from your catalog, you'll need to quit QS each time you add/remove. In my tested, just rescanning the catalog didn't do the trick. Maybe there something I don't know, but I needed to: Check/Uncheck the box for that catalog item (in the drawer), Quit QS, Launch QS, and Test in order to get clean results. Thanks for reading this far. a. |
I'm investigating that, thanks for the detailed report BTW. Hopefully I'll have a fix for it soon-ish. For the record, it's a deadlock between Trivia, |
Thanks for taking the time to read it!
That was number 1,322,457 on my "what it could be" list.
Funny enough, I do think about that when I'm in the terminal, |
Yep, it's been that way since the original HFS, 30 years ago, in System 2.1 (!), and |
That's cool. I didn't know that.
Yeah. I love how it just throws out everything you entered because of a reserved character, instead of any of at least 5 more intuitive behaviors. |
Steps:
Result:
This is a crashlog from around the time of the crash, but it's possible that it's from another crash and not related: https://gist.github.com/ar-rm/0442c3e57fb873ca3905
Versions:
QS: 1.2.2 (4011)
OS: 10.10.1
Relevant (maybe): I was previously using QS 1.0.0 (4000) and this wasn't an issue... But other things started to be, so I upgraded to 1.2.2 and this issue started. The exact same thing happened with another 10.10.1 install I was testing on an external HD. I upgraded QS to 1.2.2 and this started.
Which Plug-In does "Open With..." come from? I'd like to try disabling it. Or is it built in?
I found issue #1783, but don't know if it's actually related.
Thanks.
The text was updated successfully, but these errors were encountered: