Vscode: Editor jumps to random line when clicking into it

[toh-ableton]

Issue Type: Bug

1. Open a repo in VS Code.
2. "Find in Files" for some string.
3. Click on a search result so it opens in a new editor window.
4. Click on a line of code in this new editor window.

Expected results:
The cursor is where I clicked. The window never scrolls anywhere.

Actual results:
Often enough to be annoying, but not reliably enough to describe it, the editor scrolls to a random location in the file.

I'm sorry that I can't give you more details, but this bug is EXTREMELY annoying. If I could ask for a single thing in VS Code, it would be that you drop everything else you're working on and fix this bug. VS Code is a fantastic product, and I'm sure you have lots of ideas how to make it even better. But for my daily work, the one thing that I need is this bugfix.

VS Code version: Code 1.32.0 (507312a3e3b34b084b467dfd983263bc7c9d87e0, 2019-03-06T18:52:50.880Z)
OS version: Darwin x64 18.5.0

System Info

|Item|Value|
|---|---|
|CPUs|Intel(R) Xeon(R) W-2191B CPU @ 2.30GHz (36 x 2300)|
|GPU Status|2d_canvas: enabled
checker_imaging: disabled_off
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
native_gpu_memory_buffers: enabled
rasterization: enabled
surface_synchronization: enabled_on
video_decode: enabled
webgl: enabled
webgl2: enabled|
|Load (avg)|1, 2, 2|
|Memory (System)|32.00GB (2.80GB free)|
|Process Argv||
|Screen Reader|no|
|VM|0%|

Extensions (5)

Extension|Author (truncated)|Version
---|---|---
gitlens|eam|9.5.1
python|ms-|2019.2.5558
cpptools|ms-|0.21.0
vsliveshare|ms-|0.3.1284
vscode-capnp|xmo|1.0.0

[alexdima]

@toh-ableton I cannot reproduce this and have never experienced this issue. Is it possible that you press cmd+ or alt+ when clicking, which would cause a jump to definition?

[toh-ableton]

I can reproduce the error reliably with these steps:

1. Open a workingcopy of this repo in vscode.
2. Open the file i18n.ts.
3. Press Cmd-F and search for the string then
4. Press Cmd-Shift-F search for the string indexOf (limit files to include to i18n.ts for simplicity).
5. Click on the first search result (for me, this is i18n.ts:908 filter(p => extractedResources.indexOf(p) === -1)})`);. Note that the search box in the editor still contains the string then.
6. Move the mouse pointer to line 912 let promises: Array<Promise<void>> = []; (just move it, do not click).
7. Using the mouse-wheel, scroll up to line 880 and click on the function name findObsoleteResources.

Expected results:
The view does not move. The cursor is on line 880 where I clicked.

Actual results:
The view jumps back to line 912, and the cursor is also on line 912.

[alexdima]

Thank you for the detailed steps, but I could not reproduce. Here I am trying to reproduce, but without success:

mp4 due to gif size - Kapture 2019-03-27 at 21.24.38.mp4.zip

[toh-ableton]

This is how it looks for me: vscode-issue-70306.mov.zip

[alexdima]

oh that is horrible! Can you please try to disable all your extensions and then attempt to reproduce ?

[toh-ableton]

I disabled all extensions and restarted VS Code, but no luck. I can still reproduce the bug.

[toh-ableton]

It seems related to the setting "search.globalFindClipboard": true,. When I disable this setting, I can no longer reproduce the bug.

[roblourens]

I can reproduce this, only with both search.globalFindClipboard and editor.find.globalFindClipboard set. They are interacting somehow, and the editor find value changes which causes the editor to jump.

[vscodebot[bot]]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[roblourens]

Well, now I can't reproduce this anymore in Insiders. Do you still see itI?

[mak-ableton]

I can still reproduce the bug. This is what I did:

• Open a working copy of this repo in vscode.
• Open the file i18n.ts in two panes (e.g. via View -> Editor Layout -> Split Right)
• In the left pane, select "import" and press Cmd-E to set "import" as the search term, then Cmd-G to search for it once
• In the right pane, select "NUMBER_OF_CONCURRENT_DOWNLOADS" and press Cmd-E followed by Cmd-G
• In the left pane, select "import" again and press Cmd-E
• Click into the right pane.

Expected: The right pane gets focused and the cursor gets positioned where I clicked

Actual: The right pane scrolls all the way to the top since the click to focus it seems to trigger a find operation for "import".

Here's a video of what it looks like for me: VSCode scroll position jump.mov.zip (bad quality due to file size constraints)

The version of VSCode I was using (in case the video is too illegible):

Version 1.35.0-insider (1.35.0-insider)

5e1f9440d280b0b04cba843df6a0032bf517a2f0

2019-05-24T05:07:33.632Z

[mak-ableton]

Note that I have both globalFindClipboard options enabled:

{
    "editor.find.globalFindClipboard": true,
    "search.globalFindClipboard": true
}

[toh-ableton]

Well, now I can't reproduce this anymore in Insiders. Do you still see itI?

Unfortunately, yes, I can still reproduce the issue using my original repro steps and both search.globalFindClipboard and editor.find.globalFindClipboard set to true.

Version 1.35.0-insider (1.35.0-insider) 2737cde4facc8411982862742f5c6cd3dabef323

[mak-ableton]

I looked into this issue some more, hoping that I could contribute a fix myself. For now, I think I've found the main misunderstanding behind this bug: In https://github.com/microsoft/vscode/issues/39693#issuecomment-349831092, @rebornix states that

we read from the global find clipboard only when
(...)
Users switch from another application back to VSCode and the Find Widget is visible at the same time

(Note that this clarifies another puzzle piece necessary for reproducing this bug: The Find Widget must be visible in order to trigger the jump.)

I think that what @rebornix states it not in line with how applications normally behave on macOS. The global find clipboard should not be read on focus change, but only when invoking a search using Cmd+G. Alternatively, it would probably be acceptable if the focus change did read the global find clipboard _without triggering a search_.

I'll look some more into fixing the issue along these lines, but I know nothing about VSCode's architecture, so I'm just poking around until I maybe find something that looks like a promising way to fix this.

[mak-ableton]

I've dug some more; these are my findings:

• When FindWidget receives focus, it reads the global find buffer through this callback and changes the FindReplaceState.
• FindReplaceState fires its change event
• Among the listeners for this event is the FindModel, which triggers a research (as in "search again", not "do science", I guess :))

My gut feeling is that changing the "change FindReplaceState" -> "update FindModel" -> "trigger research" part is probably not a good idea.

It seems more promising to read the global find clipboard when performing a search command. The only places where one could put that functionality seem to be CommonFindController.moveToNextMatch or the public or private moveToNextMatch functions on the FindModel. I can't decide which one of these is the right one since I know too little about VSCode. If I had to guess I would pick the FindController.

Alternatively, one could create a completely new command for the Cmd+G shortcut which would read the global find clipboard, update the search state if necessary (which would trigger a re-search) or call findNextMatch otherwise.

[roblourens]

Good investigation, I agree with your assessment. One minor thing,

When FindWidget receives focus

This happens when the editor receives focus, just mentioning that because it confused me for a bit.

I don't really know how people commonly use this feature but the way it works now doesn't seem quite right. I have to leave this one to @rebornix...

[vscodebot[bot]]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[mak-ableton]

Could someone please reopen this? cc. @roblourens @rebornix. Looks like the bot was a bit over-eager (or rather, the "needs more info" tag should have been removed). Thanks!

[mak-ableton]

@roblourens @rebornix is there anything I can do to help move this along?

I don't really know how people commonly use this feature but the way it works now doesn't seem quite right.

I think it really boils down to what I outlined earlier:

Cmd+E: Push the selected text to the OS's global find clipboard to use it for the next search, but don't search yet.

Cmd+G: Read the OS's global find clipboard to see if its contents have changed; find the next occurrence.

On focus change: Don't do anything search-related. Especially, don't trigger a new search.

This kinda makes the "Editor › Find: Global Find Clipboard" and "Search: Global Find Clipboard" preferences obsolete: The only interaction with the clipboard should be when pressing Cmd+E and Cmd+G. I guess these could be special commands that only exist on macOS, if that fits within the cross-platform concept of VS Code.

The beauty of this feature is that I can select a word in one application and search for it in another without having to go through the copy/paste clipboard and without necessarily overwriting what I'm searching for in other applications where I don't want to search for this word: As long as I don't press Cmd+G, the global find clipboard shouldn't leak into an app. In this sense, Cmd+G is not the same as "find next": "find next" as invoked when clicking a button in the search widget shouldn't read the global find clipboard.

[adamreisnz]

I think I am running into the same issue, which has caused me endless frustrations of late, the cursor seemingly jumping to random locations in my open editors.

I have found a way to consistently reproduce, if needed (in Insiders):

1. Open two editors side by side
2. Ensure there's quite a bit of code in each file, so you can scroll around a fair bit
3. Ensure that a search term, for example foo exists in both editors
4. Ensure you use global clipboard setting on
5. In editor 1, initiate a search for a random term, say bar, then scroll around a bit, away from the term foo
6. Go to editor 2, and initiate a search there for foo. Note that the find box in editor 1 still says bar at this stage
7. Click back on editor 1 onto a line of code you want to edit
8. Observe that as soon as you click on this editor, the clipboard updates to foo, and the editor jumps to the first instance of foo that it can find.

That last bit is horribly annoying, because it takes you out of context for no reason. It should update the find box to the search term used in editor 2, yes, but it should not under any circumstances jump to the first found occurrence when I simply focus on the editor, but only do this when I press CMD+G.

[briankendall]

I just came here to report the same bug. As has been mentioned in this issue and also in #85308, the problem is related to the "global find clipboard" when running VS Code on macOS. This bug is heinously annoying and makes that feature unusable for me! I constantly lose my place in files.

Disabling "global clipboard" prevents the issue from occurring, but also disables proper clipboard behavior on macOS.

• VSCode Version: 1.42.0
• OS Version: macOS 10.14.6

[ultraGentle]

@Rebornix commented in #85308 that this behavior is connected to the editor's Auto Search 'feature' (which is confusingly named, and should be something like Auto Scroll to Matching Text).

The reason I mention it here is that there is already #60977 with some traction bemoaning other effects of Auto Search, and proposing it be adjusted.

While the specific issues aren't identical, they both involve unexpected scrolling/editor movement based on auto search, and that issue is close to the 20 upvotes needed for acceptance.

If you'd like to support that issue (and thus indirectly this one), you can do so by thumbs-upping the first post of that thread.

[koliyo]

I have the exact same issue, super annoying. "Glad" I found others with the same experience!
Hope this get adressed, this is probably my number one complaint with my VS Code experience, which is my primary editor for most projects/languages.

[ultraGentle]

@koliyo and any others who came here to support this, please remember to upvote at the first post here, and/or first post at #60977 (maybe state your reason there, since this thread is not exactly the same).

And, if the upvote policy itself wasn't clear/known to you, you can separately consider upvoting #90091 and #89652.

[lionello]

I can't repro in latest release.

Sorry, it indeed does still happen.

[mak-ableton]

I can still reproduce it in 1.43.2:

• Make sure that editor.find.globalFindClipboard is enabled
• Open two editors side-by-side
• Open the find widget in both editors by focusing each and pressing Cmd+F
• Select a word in the left editor and make sure that this word is not currently visible in the right editor. An easy way to do this is to scroll all the way down past the end of the file
• With the left editor focused, press Cmd+E
• Click on the right editor to focus it

Expected:

• The right editor gets focused, but doesn't change its scroll position

Actual:

• When focusing the right editor, its local find widget is populated with the search term and it immediately searches for this term, scrolling somewhere else.

The bold part must not happen.

Edited since I missed a crucial step to reproduce. To summarize, here are the conditions that must be fulfilled to reproduce this:

• editor.find.globalFindClipboard must be enabled
• The find widget in the editor that is being focused must be visible
• The search term must not be currently visible in the editor being focused
• The search term in the global find clipboard must be different from the one that's in the find widget of the editor being focused

[toh-ableton]

I can also still repro this in 1.43.2.

[ultraGentle]

Just wanted to update folks on this thread: I opened up a PR a while back that seems to have fixed this (and a sister issue) for me. At least one other user has also reported that it works for them.

I haven't heard back from the VSC team as to whether I need to take further action to move the PR along, so I thought I'd mention that it's a small fix, so you can easily build your own copy of VSC and cut out 3 lines to solve the issue.

So, just in case this is still driving you crazy, you can see either

91013 was the original PR, which included minor refactoring;

94622 is functionally the same, but is the 3-lines-only version.

[toh-ableton]

Just for the record: I do find cursor movement while typing into the Find Widget useful behavior. What I find highly annoying is cursor movement when clicking into a window, what this bug is about. Now I have to choose between a feature a very much want to have and a bug that's super disruptive.

I would still prefer a proper fix for this bug rather than an option to disable a feature that coincidentally disables this bug.

[rebornix]

@toh-ableton sounds reasonable to me.

[briankendall]

I agree 100% with @toh-ableton. I use the cursor movement behavior a lot in other IDEs and editors, such as Qt Creator and Sublime Text. It's a little awkward with the cursor not automatically moving when I start typing into the search box.

And of course the problem was clicking into an editor pane and the cursor suddenly jumping to an unwanted position in the file, especially if I changed the search string between when I clicked out of that editor and when I clicked back in.

[rebornix]

Agree with you all that when you just focus back into the editor, if the search term is updated by others (e.g., the global clipboard), it should not move the viewport, otherwise you lose where you were previously. Pushed a change to disable that.