I'm curious why this is being filed as a bug? this is how I'd expect it to behave.

#39585 (comment)

as per #39609 all find inputs should be automatically populated with the global search buffer.

for example, if Im to be in one workspace and cmd+e over highlighted text (places into global search buffer), Id expect to see this string in all my cocoa apps search input fields (Terminal, Safari, Chrome, etc.)

currently when I cmd+e to place in buffer in one workspace and then head to another to perform a find all, the input in the find all is not populated with the global search buffer as it should be.

@wprater thanks for your feedback. I dropped my thoughts in #39422 (comment) , the global find clipboard works the same as you described. But for this command Find Next Selection, we may want to save the selection to global find clipboard as it's what the command asks for.

@rebornix we are currently saving the selection to the global find clipboard.

You may try this by selecting a text using Cmd+E and then switching the application and using Cmd + G to find in that application.

I don't expect the search string to change on focus gain via mouse click. I have not seen any application that changes the search text on focus gain via mouse click on OSX or any other OS.

Here I do the steps I describe:

• search for "hello" in Chrome
• open VSCode
• press cmd+f3
• click in the search input
• it is unexpected that "hello" appears when clicking in there.

@alexandrudima thanks, you are right. It should not be triggered by clicking. If editor.find.globalFindClipboard: true and the clipboard service is available (macOS), we read from the global find clipboard only when

• The cursor is not on a word and there is no selection, then users run Find (Cmd+F)
• Users run Find Next (Cmd+G, F3)
• Users switch from another application back to VSCode and the Find Widget is visible at the same time

Others work the same way as before.