Alfred workflow fails to switch focus away from Word 2008

[dale]

Using Alfred's "Launch Apps / Files" workflow action to launch an application doesn't seem to correctly take focus away from Microsoft Word 2008.  I'll use TextEdit in this example, but I've also reproduced this behavior with Mail.app and Google Chrome.

 

Steps to reproduce:

1. Make a simple workflow with a no argument keyword input connected to a "Launch Apps / Files" action that launches TextEdit.  For convenience, I've created such a workflow.
2. Open TextEdit.
3. Open Microsoft Word 2008.  A blank Word document is now focused.
4. Open Alfred via keyboard shortcut, type the keyword assigned in your workflow (e.g. "example" in the workflow I provide), press enter.

Expected results:

 

TextEdit is raised and focused.

 

Observed results:

 

I'm pretty certain that TextEdit is momentarily raised and focused, but then Word is immediately raised and regains focus.  This happens so fast it appears like a flicker.

 

Alfred v2.2 (243), OS X 10.8.5.

 

Additional notes:

 

If, instead of triggering my workflow, I instead instruct Alfred to run TextEdit normally (e.g. just start typing "TextEdit" and then hitting enter once it has identified the correct application), TextEdit is raised and focused, and it remains that way.  Perhaps the "Launch Apps / Files" action could be changed to use whatever method Alfred normally uses to launch applications, if it's not already?

[Andrew]

Using Alfred's "Launch Apps / Files" workflow action to launch an application doesn't seem to correctly take focus away from Microsoft Word 2008.  I'll use TextEdit in this example, but I've also reproduced this behavior with Mail.app and Google Chrome.

 

Steps to reproduce:

1. Make a simple workflow with a no argument keyword input connected to a "Launch Apps / Files" action that launches TextEdit.  For convenience, I've created such a workflow.
2. Open TextEdit.
3. Open Microsoft Word 2008.  A blank Word document is now focused.
4. Open Alfred via keyboard shortcut, type the keyword assigned in your workflow (e.g. "example" in the workflow I provide), press enter.

Expected results:

 

TextEdit is raised and focused.

 

Observed results:

 

I'm pretty certain that TextEdit is momentarily raised and focused, but then Word is immediately raised and regains focus.  This happens so fast it appears like a flicker.

 

Alfred v2.2 (243), OS X 10.8.5.

 

Additional notes:

 

If, instead of triggering my workflow, I instead instruct Alfred to run TextEdit normally (e.g. just start typing "TextEdit" and then hitting enter once it has identified the correct application), TextEdit is raised and focused, and it remains that way.  Perhaps the "Launch Apps / Files" action could be changed to use whatever method Alfred normally uses to launch applications, if it's not already?

 

I can explain why this is happening, but it is in fact a bug in MS Word. Essentially, with the default results, Alfred doesn't force yield focus back to OS X when launching applications to give a generally smoother user experience. When running other actions (including Workflows), Alfred hides and deactivates to ensure that the focus is fully returned to OS X's last focused app. This allows things such as pasting out of OS X to occur.

 

When launching an app from a workflow, you will get a fraction of a second where the focus is returned to the previous app before OS X launches the app you have specified. The bug in Microsoft Word (and I think all MS applications) is that it sees that it has been given focus, waits a moment, then without any regard, requests to OS X to make itself focused again. This naturally gets in the way of what you are trying to do.

 

One thing which is coming to Alfred's workflows in the future is more control over how Alfred hides himself after a workflow is complete which means you should be able to side step this issue.

 

I'm moving this issue to 'noted' for now, keep an eye out in the change log for the mentioned workflow change

 

Cheers,

Andrew

[dale]

Microsoft office applications are bad OS X citizens?  No way!

 

Thanks for your response.  I'm looking forward to the additional workflow controls around hiding.

 

As a new user that just switched from Butler to Alfred a few weeks ago I'm very impressed, especially with Workflows and Script Inputs.  Great job!

[peterbraam]

I think this problem affects many workflows as follows:

 

if you type in something very fast and hit return, the workflow fails to transfer the full string to the target app (e.g. with the reminders workflow, using "r this" I create reminders named  "t", "th", "thi" and only if I slow down is the URL properly passed.

 

Will it be resolved?

[Andrew]

I think this problem affects many workflows as follows:

 

if you type in something very fast and hit return, the workflow fails to transfer the full string to the target app (e.g. with the reminders workflow, using "r this" I create reminders named  "t", "th", "thi" and only if I slow down is the URL properly passed.

 

Will it be resolved?

 

Your issue is unrelated to the listed issue above.

 

The issue you mention is related to Script based workflows where the row you are selecting is the current live row returned from the underlying workflow. If the workflow hasn't completed execution, as far as it is concerned, you are selecting the correct row. This will only affect workflows which are slow at updating results to Alfred, most (especially non web based ones) should be instant.

 

Having said that, I have planned passing out the currently typed query throughout the workflow which may enable workflow developers to catch similar to what you describe (which may or may not be the desired behaviour).