I cannot reproduce:

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!

• VSCode Version: Code 1.19.0 (816be67, 2017-12-14T12:06:43.492Z)
• OS Version: Windows_NT x64 10.0.16299
• Extensions: none

I just repro'd this with the latest stable version, no extensions, everything at stock defaults. You have to hit the keybindings very quickly. Maybe some sort of race condition.

The cursor doesn't always move to the beginning of the file, sometimes it moves somewhere in the middle. I think it's related to where the cursor is in the other editor.

My easiest repro is:

1. Open 2 editors, one less than a full page (doesn't scroll), one more than a full page (scrolls).
2. Move the cursor in each editor to the end of the file.
3. Jump back and forth as fast as you can.
4. Notice the cursor in the longer file moves to the line number matching the last line of the shorter file, and/or
5. Notice the cursor in the shorter file stays in the correct place, but the contents are scroll out of view.

In the GIF above the first file is 33 lines and the second is 183 lines. The cursor starts at the bottom of each. After jumping between editors a few times you see the cursor in the second file is suddenly at line 33, not line 183 where it started.

@alexandrudima Do I need to create a new issue for this or can it be reopened?

Thank you @akbyrd . I have been able to reproduce locally. It is indeed some form of race condition.

@bpasero I've added the following keybindings:

    {
        "key": "ctrl+alt+right",
        "command": "workbench.action.nextEditorInGroup"
    },
    {
        "key": "ctrl+alt+left",
        "command": "workbench.action.previousEditorInGroup"
    }

Keeping one of them pressed or rapidly running them will repro for me.

I have added a trace to figure out who changes the cursor position, and the only trace that shows up is the restoreViewState call. I can only assume that there might be some race in textFileEditor.ts. IIRC, we've seen something similar in the past where the title of the tab would reflect the new file, while the content would reflect the old file. Perhaps this is a variation of the same problem.

setStates 
    at Cursor.setStates (file:///Users/alex/src/vscode/out/vs/editor/common/controller/cursor.js:127:40)
    at Cursor.restoreState (file:///Users/alex/src/vscode/out/vs/editor/common/controller/cursor.js:197:18)
    at CodeEditor.CommonCodeEditor.restoreViewState (file:///Users/alex/src/vscode/out/vs/editor/common/commonCodeEditor.js:456:33)
    at CodeEditorWidget.restoreViewState (file:///Users/alex/src/vscode/out/vs/editor/browser/widget/codeEditorWidget.js:291:47)
    at file:///Users/alex/src/vscode/out/vs/workbench/parts/files/browser/editors/textFileEditor.js:104:36
    at Object.notifySuccess [as _notify] (file:///Users/alex/src/vscode/out/vs/base/common/winjs.base.raw.js:1170:59)
    at Object.enter (file:///Users/alex/src/vscode/out/vs/base/common/winjs.base.raw.js:852:30)
    at _Base.Class.derive._creator._run (file:///Users/alex/src/vscode/out/vs/base/common/winjs.base.raw.js:1068:29)
    at _Base.Class.derive._creator._completed (file:///Users/alex/src/vscode/out/vs/base/common/winjs.base.raw.js:1036:18)
    at CompletePromise_ctor.CompletePromise_then [as then] (file:///Users/alex/src/vscode/out/vs/base/common/winjs.base.raw.js:1566:49)

Yeah indeed same underlying issue as #34697. Marking as duplicate.

Found a workaround by checking that the view state we want to save has the same URI as the input we save it for.

Verified that cursor position is lot lost, but I see a similar issue with folding regions: #42738