v1 versus v2 difference: Focus not returned to pre-Alfred trigger app

[ostertoaster]

Prior to upgrading to version 2, here is how a collection of apps worked:

• I would be in Terminal or iTerm, connecting to an SSH server
  
• When the SSH password prompt would come up, I would:
  
  • Trigger Alfred v1
    
  • Type in the name of the app, which is a wrapper around a command line argument built for a specific keychain item
    
  • The app would launch, and if I hadn't unlocked the keychain recently (based on timeout) I would enter my keychain password
    
  • The script would pipe the password to the pbcopy command 
    
  
  
• When the prior would finish, I'd have focus back in the terminal app, and could Command+V paste the password
  

After upgrading to v2, the above still works, but after the pbcopy cmmand completes, I don't have focus back in the terminal application. :/

 

This has been replicable on all Alfred builds through 2.0.1 (haven't had an opportunity to try 2.0.2 as I don't have that computer).

 

The OS is the latest release of Lion (10.7), though a colleague of mine who uses the same thing experienced the same thing on the latest release of Mountain Lion (10.8).

 

Maybe there's a way to remove the need for this with workflows (not sure if the CLI that does the heavy lifting can be made to return results for a script filter?) but getting back focus would be an easy and welcome fix.

 

Thanks!

Mike

[jdfwarrior]

Prior to upgrading to version 2, here is how a collection of apps worked:

• I would be in Terminal or iTerm, connecting to an SSH server
• When the SSH password prompt would come up, I would:
  • Trigger Alfred v1
  • Type in the name of the app, which is a wrapper around a command line argument built for a specific keychain item
  • The app would launch, and if I hadn't unlocked the keychain recently (based on timeout) I would enter my keychain password
  • The script would pipe the password to the pbcopy command 
• When the prior would finish, I'd have focus back in the terminal app, and could Command+V paste the password

After upgrading to v2, the above still works, but after the pbcopy cmmand completes, I don't have focus back in the terminal application. :/

 

This has been replicable on all Alfred builds through 2.0.1 (haven't had an opportunity to try 2.0.2 as I don't have that computer).

 

The OS is the latest release of Lion (10.7), though a colleague of mine who uses the same thing experienced the same thing on the latest release of Mountain Lion (10.8).

 

Maybe there's a way to remove the need for this with workflows (not sure if the CLI that does the heavy lifting can be made to return results for a script filter?) but getting back focus would be an easy and welcome fix.

 

Thanks!

Mike

 

Could you possibly share the script with me so that I can take a look at creating a potential solution for this?

[ostertoaster]

Hi David,

 

Sure! What's the best way to get the files to you?

 

-Mike

[joseluisdgz]

This issue happens to me too, but with Finder (using TotalFinder). I open a folder using Alfredv2 and then I open another folder and the second Finder window opens in the background of the previous opened window, so it's very frustrating when you want, for example, copy some files, open destination folder and paste them just using the keyboard. First the finder window appears in the foreground and one second after jumps to the background. I didn't have this issue with Alfredv1.

I'm using Alfred v2.0.2(178) with PowerPack license. My OSX version is Mountain Lion 10.8.3.

 

If you need more information, just let me know.

 

Thanks for your support.

[Andrew]

This issue happens to me too, but with Finder (using TotalFinder). I open a folder using Alfredv2 and then I open another folder and the second Finder window opens in the background of the previous opened window, so it's very frustrating when you want, for example, copy some files, open destination folder and paste them just using the keyboard. First the finder window appears in the foreground and one second after jumps to the background. I didn't have this issue with Alfredv1.

I'm using Alfred v2.0.2(178) with PowerPack license. My OSX version is Mountain Lion 10.8.3.

 

If you need more information, just let me know.

 

Thanks for your support.

 

How are you opening the two folders in Alfred?

[joseluisdgz]

I open Alfred. Start typing folder name. When Alfred finds the folder and the folder is highlighted, I press return to open it. When the first finder window is open, I open Alfred again and start typing second folder name. I press return as well and the second finder window opens and appears one second in the front and then is sent behind the first opened window. 

[Andrew]

I open Alfred. Start typing folder name. When Alfred finds the folder and the folder is highlighted, I press return to open it. When the first finder window is open, I open Alfred again and start typing second folder name. I press return as well and the second finder window opens and appears one second in the front and then is sent behind the first opened window. 

 

I wonder if this is a TotalFinder issue as when I find Desktop in Alfred and press enter, Finder opens with Desktop. If I then find Documents in Alfred and press enter, Finder opens with Documents at the front.

 

Perhaps you could create a new profile on your Mac without TotalFinder to see?

[joseluisdgz]

You are right. It's a TotalFinder issue. I checked it.

 

Thanks for your help.

[ostertoaster]

Checking in to see on the status of this one after seeing the 2.0.7 release email. Many updates later, this is still a problem, and it's keeping a couple colleagues stuck on Alfred 1.x (I'm just living with it).

 

Happy to resend the script to the Alfred Team to help reproduce the issue.

[Andrew]

Checking in to see on the status of this one after seeing the 2.0.7 release email. Many updates later, this is still a problem, and it's keeping a couple colleagues stuck on Alfred 1.x (I'm just living with it).

 

Happy to resend the script to the Alfred Team to help reproduce the issue.

 

If a second app launches, the focusing is outside of Alfred's control so I can't see how the focus would be returned to terminal anyway (Alfred 1 or 2 doesn't actually perform any focusing, it just yields back to the OS after a command is run).

 

In your workflow, what action type are you using?

[ostertoaster]

Andrew, sorry for the major lag in responding.

 

It's not a workflow, but an actual app that gets invoked via Alfred. Under the hood, it's an app bundle that invokes a shell script:

 

Where KeychainEntry is the name of the entry in the Keychain, the shell scrip is located here:

 

[KeychainEntry].app/Contents/MacOS/[KeychainEntry]

#!/bin/bash
PW=`python -c "print '$0'.split('/')[-1],"`
~/bin/getpw "$PW" |pbcopy

If the Keychain is unlocked, then it will simply copy the entry password. If it hasn't been unlocked, you must first authenticate to unlock it.

 

It worked (and continues to work) flawless in Alfred 1.x, in the sense that focus always ends up coming back to the pre-invocation window, which is usually Terminal.app or iTerm.app.

 

If you think Keychain entries can be access in this fashion using a workflow, I'm more than happy to head down that rabbit hole. The important thing would be that it behave like 1Password integration in that individual entries would come up in search.

 

As I did for David, I'm happy to send a manifesto of how the framework functions. There's a master app (refreshallpw) that uses the shell command "security dump-keychain" to find all entries of interest and generate the individual .app bundles for each entry.

 

Thanks for any light you can shed on this, or any path forward!

[jpotterm]

This issue is keeping me on v1 as well. I use Plain Clip launched via Alfred; v1 returns focus correctly but v2 doesn't. Here are steps to reproduce.

1. Launch Chrome and put cursor in a form field.
2. Cmd-Space to open Alfred
3. Type "plain" and hit enter to launch Plain Clip
4. Check focus

In v1 step 4 will have your cursor still in the text field ready to type. In v2 Chrome in general will have focus, but not the window nor the text field, so you have to click the text field again before typing.

[jpotterm]

Has there been any progress on this, or is there somewhere else I should submit a bug report instead?

[Andrew]

Has there been any progress on this, or is there somewhere else I should submit a bug report instead?

 

Alfred 2's window / focus subsystem were changed by design so there isn't a bug in this area. If you had the Powerpack, you have better control over this and would be able to yield the focus differently.

 

Cheers,

Andrew

[ostertoaster]

Hi Andrew,

 

I realize you're responding to jpotterm, but I do in fact have a PowerPack. I responded to your query about what workflow action type I'm using, and I responded that I'm not using a workflow and provided more details.

 

If there's a way to wrap these apps or perform that same action--getting the password from specific Keychain entries--in a workflow, I'd be happy to work on converting over to that if it means that the focus issue would be resolved. All I'd ask is a pointer to what workflow action(s) would be most effective, or a pointer to an existing workflow that could serve as an example.

 

Thank you,

Mike

[Andrew]

Hi Andrew,

 

I realize you're responding to jpotterm, but I do in fact have a PowerPack. I responded to your query about what workflow action type I'm using, and I responded that I'm not using a workflow and provided more details.

 

If there's a way to wrap these apps or perform that same action--getting the password from specific Keychain entries--in a workflow, I'd be happy to work on converting over to that if it means that the focus issue would be resolved. All I'd ask is a pointer to what workflow action(s) would be most effective, or a pointer to an existing workflow that could serve as an example.

 

Thank you,

Mike

 

Have you tried simply creating a workflow to run that script directly? Workflows have a different deactivation mode to the default results.

 

Cheers,

Andrew

[ostertoaster]

Not yet.

The workflow would need a keyword to trigger the workflow, then filter a list of potential keychain entries. Selecting a keychain entry would then trigger the script to unlock and copy the password. Do you know of a plugin I could look at to figure out that second part--filtering a list of possible entries? The list would come out of a shell script that is running the "security dump-keychain" command.

I certainly am not asking for anyone to write a workflow for me, but rather looking for an example to start from in the (internet) age-old cookbook tradition.

Thank you,

Mike

[ostertoaster]

It looks like the list of Keychain Items might be achieved using a Script Filter? I checked the Alfred 2 workflow tutorials page, but found this feature's page empty. I'm happy to peruse through the forums, but want to make sure I'm headed down the right rabbit hole before I do.

[Andrew]

It looks like the list of Keychain Items might be achieved using a Script Filter? I checked the Alfred 2 workflow tutorials page, but found this feature's page empty. I'm happy to peruse through the forums, but want to make sure I'm headed down the right rabbit hole before I do.

 

I think making a request in the workflow help sub-forum would be a better place to start than in this sub-forum as you will get plenty more eyes on this issue... in many cases, you will indeed have somebody help create the workflow.