Clipboard pastes to wrong window when multiple windows are open

[Dan Horne]

Alfred v2 pastes to the FIRST window of an application instead of the ACTIVE window.

 

Steps to reproduce:

1. Open a Google Chrome window and click to put the cursor in the address field (or any other field).
2. Open a second Google Chrome window and do the same.
3. Attempt to paste something into the second Chrome window from Alfred's clipboard history or snippets.
4. Alfred v2 pastes it into the first Chrome window instead of the active Chrome window.

This happens every time the above situation occurs.  I also tested with Firefox, and the same behavior occurs, so it doesn't seem to be a Chrome issue.

 

I have selected "Auto Paste on return" in Alfred's Clipboard->Advanced settings.

 

OS X 10.9

Alfred v2.1.1 (227)

 

Edited for clarity.

Edited December 16, 2013 by Dan Horne

[Tyler Eich]

I followed your steps, but I can't reproduce the issue. I, too, have "Auto Paste on return" activated.

 

Alfred 2 v2.1.1 (227) on OS X 10.9 (13A603)

Edited December 16, 2013 by Tyler Eich

[Andrew]

Alfred v2 pastes to the FIRST window of an application instead of the ACTIVE window.

 

Steps to reproduce:

1. Open a Google Chrome window and click to put the cursor in the address field (or any other field).
2. Open a second Google Chrome window and do the same.
3. Attempt to paste something into the second Chrome window from Alfred's clipboard history or snippets.
4. Alfred v2 pastes it into the first Chrome window instead of the active Chrome window.

This happens every time the above situation occurs.  I also tested with Firefox, and the same behavior occurs, so it doesn't seem to be a Chrome issue.

 

I have selected "Auto Paste on return" in Alfred's Clipboard->Advanced settings.

 

OS X 10.9

Alfred v2.1.1 (227)

 

Edited for clarity.

 

I've also been unable to reproduce this - Alfred pastes to the active window in every case.

 

Do you have any window managers installed, or any 3rd party apps which could be affecting this?

[GoldenGecko]

I have had a very similar problem, and I think that it could be due to the way Mavericks handles multiple monitors. If I have XCode open with one project open on each window, and try to paste using Alfred, it always goes to one project, even if I have been editing in the other project.

 

This dramatically reduces the usefulness of the product, so would appreciate if you could investigate.

[Andrew]

I have had a very similar problem, and I think that it could be due to the way Mavericks handles multiple monitors. If I have XCode open with one project open on each window, and try to paste using Alfred, it always goes to one project, even if I have been editing in the other project.

 

This dramatically reduces the usefulness of the product, so would appreciate if you could investigate.

 

I've tried every combination I can of Xcode with two different projects open on two different screens with Alfred set to both show / not show on the active screen and Alfred still pastes to the currently active window.

 

Do you have any 3rd party apps or modifications to OS X which could affect window behaviour?

 

Cheers,

Andrew

[Dan Horne]

This problem persists.  I'm not sure what other programs might interfere.  I don't have any window managers installed that I know of, just OS X.  

 

I notice it most in Chrome.  Here is my exact display setup:

 

15" Macbook Pro internal display, 24" external display connected via displayport-to-dvi cable.  My external monitor is set as the primary display, and I can only remember it happening when trying to paste into Chrome on the external monitor, while another Chrome window is also open on the internal display.  In this case, Alfred always tries to paste into the Chrome window on the internal display.

[hustoj2]

Did you ever figure this out? I'm experiencing the same issue, and it is a significant problem. I end up accidentally editing spreadsheets on the wrong screen when I try to paste from history. I suppose the work around is to disable Auto Paste. I'll circle back to try to come up with more specific steps, but here's what I've got right now:

 

Prereqs:

* 24" iMac, plus 27" Thunderbolt display. OS X Mavericks 10.9.4.

* Auto Paste on return = true

 

Steps:

1. Open multiple windows of Google Chrome, at least one on each monitor

2. [unknown steps that I have not been able to decipher, possibly requiring a significant amount of time].

3. Copy text from any application window (not just Chrome) on the external monitor

4. Highlight a Google Chrome window on the iMac's display.

5. Invoke clipboard history, and select any item in the list.

 

Expected:

* Text is pasted into the highlighted Google Chrome window on the iMac

 

Actual

* Text is pasted into a Google Chrome window on the external monitor

 

Notes:

* I do have an application called Command-C running on my Mac. I'll disable that and see if this problem still recurs again.

* I do use the Hangouts plugin for Google Chrome, which seems to cause other keyboard issues within Chrome from time to time. I believe I was experiencing this before I installed the Hangouts plugin, though. If I close the Hangouts plugin while this issue is occurring, the issue continues to occur.

* Even when this is happening, the normal paste command does paste into the correct window.

* I have experienced this with Google Chrome, and with Xcode. Not sure about other programs.

* If I close and re-open Xcode, I can't reproduce the problem immediately. It's something that appears to come up over time. If it was affecting both Google Chrome and Xcode, closing and reopening Xcode will resolve it only for Xcode while leaving Chrome still affected. If I subsequently close and reopen Chrome, that will then fix it for Chrome.

* I've tried changing which monitor is the primary (by dragging the little white bar from one monitor to the other in System Preferences > Display > Arrangement). That doesn't seem to have an impact on which monitor receives the text when this bug occurs, but I haven't done a ton of independent testing on this aspect.

[Andrew]

 

Did you ever figure this out? I'm experiencing the same issue, and it is a significant problem. I end up accidentally editing spreadsheets on the wrong screen when I try to paste from history. I suppose the work around is to disable Auto Paste. I'll circle back to try to come up with more specific steps, but here's what I've got right now:

 

Prereqs:

* 24" iMac, plus 27" Thunderbolt display. OS X Mavericks 10.9.4.

* Auto Paste on return = true

 

Steps:

1. Open multiple windows of Google Chrome, at least one on each monitor

2. [unknown steps that I have not been able to decipher, possibly requiring a significant amount of time].

3. Copy text from any application window (not just Chrome) on the external monitor

4. Highlight a Google Chrome window on the iMac's display.

5. Invoke clipboard history, and select any item in the list.

 

Expected:

* Text is pasted into the highlighted Google Chrome window on the iMac

 

Actual

* Text is pasted into a Google Chrome window on the external monitor

 

Notes:

* I do have an application called Command-C running on my Mac. I'll disable that and see if this problem still recurs again.

* I do use the Hangouts plugin for Google Chrome, which seems to cause other keyboard issues within Chrome from time to time. I believe I was experiencing this before I installed the Hangouts plugin, though. If I close the Hangouts plugin while this issue is occurring, the issue continues to occur.

* Even when this is happening, the normal paste command does paste into the correct window.

* I have experienced this with Google Chrome, and with Xcode. Not sure about other programs.

* If I close and re-open Xcode, I can't reproduce the problem immediately. It's something that appears to come up over time. If it was affecting both Google Chrome and Xcode, closing and reopening Xcode will resolve it only for Xcode while leaving Chrome still affected. If I subsequently close and reopen Chrome, that will then fix it for Chrome.

* I've tried changing which monitor is the primary (by dragging the little white bar from one monitor to the other in System Preferences > Display > Arrangement). That doesn't seem to have an impact on which monitor receives the text when this bug occurs, but I haven't done a ton of independent testing on this aspect.

 

 

Have you tried setting Alfred to display on your primary active screen? You can do this in Alfred's Appearance > Options > Show Alfred on...

 

Cheers,

Andrew

[hustoj2]

@Andrew thanks for the fast response! If I were trying to do an independent test, I'd leave my "Show Alfred on" setting alone. But I'll be selfish and try all the things. Will post back to this thread if I learn more.

[evansj]

I am experiencing the same symptoms with a similar setup. MacBook Pro with external monitor, multiple Textmate windows open, when I paste from clipboard history it switches back to the main MacBook display and pastes into a Textmate window there, instead of the one I was using on the external monitor. It happens with other apps too.

 

I already have Alfred configured to open on the active desktop. I'm on OSX 10.9.4, MBPR 15", with external DVI monitor connected via DisplayPort.

[Andrew]

I am experiencing the same symptoms with a similar setup. MacBook Pro with external monitor, multiple Textmate windows open, when I paste from clipboard history it switches back to the main MacBook display and pastes into a Textmate window there, instead of the one I was using on the external monitor. It happens with other apps too.

 

I already have Alfred configured to open on the active desktop. I'm on OSX 10.9.4, MBPR 15", with external DVI monitor connected via DisplayPort.

 

I suspect that some applications are creating this behaviour, e.g. here is Terminal.app's behaviour outside of Alfred:

 

http://www.alfredforum.com/topic/4721-clipboard-history-pastes-into-wrong-terminal-window-when-on-different-displays

 

Are there specific apps it works in and doesn't work in on your configuration?

[hustoj2]

I was about to declare victory on this after making the modifications from posts #7 and #8 on this thread, but this issue just flared up again.

 

I have seen the issue occur in both Xcode and Google Chrome in the past. Currently however, it is happening in Chrome but NOT in Xcode. I'm not sure if that tells us anything new about the issue.

 

 

I reviewed your thread where you talked about Terminal.app's behavior where it switches focus back to the original window, and I think you are on to something there. Here's some additional testing I did:

1. I brought the affected program to the foreground, used shortcuts to show Alfred, and then hit escape. Note that I have "Show Alfred On... Active Screen" enabled.

1a. For the currently affected program (Google Chrome), it always returned focus to the Chrome window on my Thunderbolt display (which is selected as the primary window in System Prefs), no matter which Chrome window was highlighted prior to invoking Alfred.

1b. For unaffected programs, the system focus was correctly restored to the same in-focus window as before invoking Alfred.

2. I also tried switching to a different program besides Alfred (using CMD-TAB), and then switching back to the original program.

2a. For the currently affected program, the behavior was the same as when switching to/from Alfred. It always made the window on my Thunderbolt the in-focus window.

2b. For unaffected programs, the focus was sent to a window on the same display as the in-focus window on the previous app. Note that this is not the same behavior as when invoking Alfred and hitting escape.

 

@Andrew:

3. My findings in 2b were unexpected to me, but I assume this is why you recommended I enable "Show Alfred On... Active Screen"?

4. I'm starting to buy that this bug is not an issue with Alfred, but it's still troubling that there seems to be no way around it (according to your post on the Terminal.app thread). Especially since the system Paste command still functions as expected. I'm not familiar with the Apple APIs you have access to for developing Alfred, but I have a few followup questions/ideas:

4a. When pasting from Clipboard history, do you currently find the last active program, find the in-focus window for that program, find out where the cursor is in that window, and then paste in the text manually?

4b. Is there any way for you to query/detect where the system Paste command will be sent, and use that same location?

4c. Assuming something like 4a is true, is there any way to feed text directly into the system Paste command when invoking a paste from clipboard history, rather than inserting the text in the field manually?

 

Thanks again for taking the time to investigate this issue!

[Andrew]

4a. When pasting from Clipboard history, do you currently find the last active program, find the in-focus window for that program, find out where the cursor is in that window, and then paste in the text manually?

4b. Is there any way for you to query/detect where the system Paste command will be sent, and use that same location?

4c. Assuming something like 4a is true, is there any way to feed text directly into the system Paste command when invoking a paste from clipboard history, rather than inserting the text in the field manually?

 

Thanks again for taking the time to investigate this issue!

 

Hey there,

 

Alfred really isn't doing anything clever, he is simply deactivating / hiding himself, waiting a moment, then asking OS X to paste. He isn't doing anything to detect or change focus, it's OS X which passes focus back to the previously focused app... and that app then does whatever it likes with it. It was my findings with Terminal.app that kinda shows that regardless of what Alfred does, if that previous app wants to change which window has focus, there isn't a huge amount Alfred can do about this.

 

I am keeping an eye on this though, and will likely start raising issues with Apple if they don't generally get fixed (things like this generally stop and start working through different releases of OS X as they make changes to their apps).

 

Cheers,

Andrew

[hustoj2]

I am keeping an eye on this though, and will likely start raising issues with Apple if they don't generally get fixed (things like this generally stop and start working through different releases of OS X as they make changes to their apps).

 

 

Makes sense. Thanks again for the responses. I still wish I could figure out how to reproduce this bug though, so it would be easier to retest on future OS X releases!

[hustoj2]

Doesn't seem to be fixed in OS X 10.10 Yosemite.