Roslyn: Problem with F12 (Edit.GoToDefinition): After jumping to a different file the cursor disappears

[vsfeedback]

_This issue has been moved from a ticket on Developer Community._

---

[regression] [worked-in:Visual Studio Community 2017, Version 15]
In Version 16.4.0 Visual Studio Community 2019 there is a problem with the keyboard shortcut F12, that executes the command 'Edit.GoToDefinition'.

If the definition of the class, method or other type is stored within the currently edited document, the command works as expected: The cursor jumps to the end of the type's name.

If the definition is in a different document, the cursor is invisible after jumping to that document. The cursor can still be moved with the keyboard and the IDE highlights the current line as usual though.

---

Original Comments

florianfueger on 12/4/2019, 10:33 AM:

Edit: The problem doesn't occur if used e.g. on System.Double.

Steps to reproduce:
- Implement one class with name 'ClassA.cs' in one file.
- Implement a second class with name 'ClassB.cs' in a different file.
- In 'ClassB.cs', create a field of type ClassA.
- Position the cursor on the field's type, ClassA, and press F12 --> The IDE jumps to the file 'ClassA.cs' and the cursor disappears.

Visual Studio Feedback System on 12/4/2019, 10:53 PM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

Visual Studio Feedback System on 12/18/2019, 00:28 AM:

This issue is currently being investigated. Our team will get back to you if either more information is needed, a workaround is available, or the issue is resolved.

florianfueger on 12/18/2019, 07:30 AM:

Thank you very much. If you need further information on this, tell me and I will gladly submit it.

Visual Studio Feedback System on 1/22/2020, 06:13 PM:

This issue is currently being investigated. Our team will get back to you if either more information is needed, a workaround is available, or the issue is resolved.

Виктор Локтев on 2/14/2020, 07:30 AM:

I have the same issue.

All versions of my Visual Studios before 2019 time to time lost cursors.

In msvs 2019 my cursor disappears after F12. The conditions are:

• 1) Class is in my own code (not system class)
• 2) Set Tab Layout -> Left or Right. If “Top” all is ok.
• 3) Ctrl+Tab and one more Ctrl+Tab returns my cursor back visible.

Microsoft Visual Studio Community 2019

Version 16.4.5

Additionally installed: Collapse Region extension and Tame Visual Studio Editor Tooltips.

Loading Visual Studio settings saved after installation doesn’t help.

When cursor is hidden editing works ok, just there is no cursor.

Виктор Локтев on 2/19/2020, 05:20 AM:

Well,

I have found the following

Step 1. Press F12 to navigate to a file A - file A is opened in preview - tab on the right side of a window.

Step 2. Press F12 to navigate from file A to file B - file B replaces file A in preview tab. This is important.

File B must replace A in preview. If A or B is already opened or opened not in preview, everything is ok.

The solution is to disable open files in preview:

Tools -> Options -> Environment -> Tabs and Windows -> Preview Tab -> uncheck "Allow new files to be opened in the preview tab".

Виктор Локтев on 2/19/2020, 06:24 AM:

Also

check this

https://github.com/dotnet/roslyn/issues/36452

Виктор Локтев on 2/19/2020, 11:09 PM:

Same problem is here

https://developercommunity.visualstudio.com/content/problem/625201/disappearing-cursor-in-text-editor-vs-2019.html

Виктор Локтев on 2/20/2020, 00:07 AM:

Unfortunately, turning off preview did not solve the problem incompletely for me.

Виктор Локтев on 2/20/2020, 01:13 AM:

If navigation from A to B losses cursor (caret),

open B on second monitor and navigate from A to B again.

In this case class B became selected but caret stays at same place in A.

More links:

https://github.com/dotnet/roslyn/issues/36452

https://developercommunity.visualstudio.com/content/problem/625201/disappearing-cursor-in-text-editor-vs-2019.html

Jarosław Jasiński on 4/14/2020, 00:39 AM:

Disabling 'open files in preview' does not help.

I checked in the old version of Visual Studio 16.4.1 editor (Edit.GoToDefinition) was working correctly. Then upgraded Visual Studio to current version 16.5.3 and the problem with disappearing cursor exists.

Виктор Локтев on 4/14/2020, 00:43 AM:

I have the problem with disabled 'open files in preview' in both Visual Studio 2017 and 2019.

Jarosław Jasiński on 4/15/2020, 00:36 AM:

I've upgraded Visual Studio to 16.5.4. Problem is still not fixed.

Andrew Hall 🤘 [MSFT] on 4/15/2020, 01:44 PM:

Thank you all for the reports. We're still actively tracking down the issue and working to a resolution.

I have some clarifying questions:
Does this happen for all "Go to definition" experiences (f12)?
Does this happen for "Find references" (shift+f12) as well?
Does this happen only for preview editors (they show up as purple tabs, and don't stay permanently in the editor tabs)?

alessandrot60 on 4/15/2020, 02:04 PM:

Andrew: My comment about the disappearing caret was merged into this Problem for some reason, but my problem had nothing to do with F12 / GotoDefinition. In my case, it occurred (and still occurs) in the context of a Find in Files. It is difficult to reproduce. I have been doing all the updates and now have version 16.5.4. It happened again last week.

Here is the scenario, which I already described once: I have two or more editor windows open inside Visual Studio, say a "left" window and a "right" window. I do a Find in Files, then press F4 multiple times to go through the items in the search results. As I press F4, the file containing the next item will be showed (possibly opened, or just brought up) into the "left" or into the "right" editor window. In most cases, the caret will go to the position of the item in the correct editor window, but sometimes the caret will remain in the previous window. When this occurs, if I start typing, the new characters will be inserted at the correct position in the correct window, but the blinking caret will remain in the previous window. In other words, I am typing without seeing where I am typing. The insertion point for the new text entered via the keyboard has been divorced from the caret.

jonas on 4/15/2020, 02:10 PM:

> Does this happen for all "Go to definition" experiences (f12)?

Only when they are in a different tab group (editor area split in more than one part)

> Does this happen for "Find references" (shift+f12) as well?

Same thing. As long as the reference I F8 to is in a different tab group, it doesn't focus the file and line, but if it is in the same tab group, it works.

> Does this happen only for preview editors (they show up as purple tabs, and don't stay permanently in the editor tabs)?

Nope, this problem seems to have more to do with tab group than whether the editor is a preview or not.

florianfueger on 4/15/2020, 02:15 PM:

Hello Mr Hall,

I'd like to answer your questions. Prerequisite for this to happen for sure is that the document tabs are docked to the left (using right-click on the tabs, then "Set Tab Layout" and then "Place Tabs on the Left"). This can be seen in my screenshots that I submitted as a comment on Jan 22 below.

To answer your questions:

1. Does this happen for all "Go to definition" experiences (f12)?

If the above given prerequisite is met, then the answer is yes. If you press F12 while the caret is positioned on a class, that is defined in a separate file, the cursor disappears after the file has been opened. The line is highlighted but there is no blinking cursor. If you press ArrowDown, the line marking will jump to the next line, but the cursor won't appear. Only clicking into the document will make the cursor appear. Follow the 'steps to reproduce' that I gave on Jan 22 to see what I mean.

2. Does this happen for "Find references" (shift+f12) as well?

No, in this case the cursor is visible after a jump to the reference. If you use my example and position the cursor on 'ClassA' in the file ClassA.cs, then pres Shift-F12 and double-click the found reference, Visual Studio 2019 will open the class ClassB, position the cursor at the start of the type name, 'ClassA', the cursor being visible and blinking.

3. Does this happen only for preview editors (they show up as purple tabs, and don't stay permanently in the editor
tabs)?

No, this does not happen on purple tabs. If you create for example a private field with 'string a;', position the cursor on the type name 'string' and press F12, System.String will be opened in a purple tab with a visible cursor. Thanks for your continued efforts! I wish you success in finding the solution.

And I wish you, that you and all of your relatives and friends stay healthy!

Yours sincerely

Florian Füger

Andrew Hall 🤘 [MSFT] on 4/15/2020, 02:45 PM:

@alessandrot60 I'm sorry your comment got lost. I'm trying to consolidate issues to help clearly separate problems to be addressed. I opened a new issue to make sure it's properly captured at https://developercommunity.visualstudio.com/content/problem/992637/find-in-files-occasionally-loses-cursor.html

If you happen to get a repro, please go add it to that issue.

alessandrot60 on 4/15/2020, 03:35 PM:

@Andrew Thanks. Could the underlying cause be the same? It seems that in both cases, the operation (a GoToDefinition, GoToNextLocation, etc.) moves the insertion point for keyboard input to a certain position in a certain editor window but the blinking caret remains where it was.

Andrew Hall 🤘 [MSFT] on 4/15/2020, 03:39 PM:

@alessandrot60 it's possible, but for now we are investigating them as separate issues.

Jarosław Jasiński on 4/15/2020, 11:00 PM:

> Does this happen for all "Go to definition" experiences (f12)? > Does this happen only for preview editors (they show up as purple tabs, and don't stay permanently in the editor tabs)? Yes, almost for all. It does not matter if option "Allow new files to be opened in the preview window' is checked or not. I'm almost 100% sure that in 16.5.3 option 'Set tab layout' had no effect. But in 16.5.4 setting 'Set tab layout' to "Place tabs on the top" fixes the problem. Problem exists if tabs are on the left or right.

> Does this happen for "Find references" (shift+f12) as well? "Find references" (shift+f12) causes cursor to disappear but it rather a 'feature' not a bug. "Find references" opens a new tab named "... references" at the bottom of the screen and makes it focused. Probably for people that don't use shortcuts. Fortunatelly, pressing F8 (Go to next location on the list) brings both cursor and focus back to the editor window.

---

Original Solutions

jonas solved on 4/15/2020, 02:57 PM, 0 votes:

Thank you for looking into this. I have this problem both at work and at home. I have tried a fresh install without any imported settings or extensions, and still had the issue.

The only thing I can think of right now that could stand out is that both computers are stationary, have 4k screens and Nvidia GeForce GTX graphics cards. At work it's a 1060 I think, and at home it's a 1070 ti. My nearest colleague who doesn't have this problem has some kind of AMD graphics card and dual 1920x1200 screens.

I still have this problem when I RDP to work from home, though, so graphics card vendor probably doesn't matter.

jonas on 4/15/2020, 04:12 PM:

This solution was obviously meant to be a comment, and now I can't delete it.

That's what happens when you try to use your phone, I guess.

Visual Studio Feedback System solved on 1/21/2020, 09:53 PM, -4 votes:

We are unable to investigate this issue further without the additional information requested.

florianfueger on 1/22/2020, 06:58 AM:

Unfortunately I have missed your request for further information. Please tell me, which information you need. I will submit it.

florianfueger on 1/22/2020, 07:19 AM:

Steps to reproduce the issue:

1. Create a new solution: A windows console application, C#, with .NET framework.

2. Implement a class named 'ClassA' in a new file. Make it public.

3. Implement a class named 'ClassB' in a new file. Make it public.

4. In 'ClassB' create a field of type 'ClassA'.

5. Position the cursor on the word 'ClassA' in the line 'private ClassA _classA' (line 11), and press 'F12'. After the jump to 'ClassA.cs' the cursor is not visible.

You can press 'cursor down' to see the cursor jump to the new line, but it will not become visible.

The cursor will become visible again if you click on a random location within the editor.

[liqube]

I can confirm this being an issue for at least a year now. Cannot add much information, most has been said in many threads and the original comments before.
Using on dual-head system, primary screen at 125% scale, secondary at 100% scale, happens on both screens.
In previous versions of VS2019 an ESCAPE press restored the cursor. In the latest versions it is impossible to get the cursor back without inconsistently mouse-clicking around the editor several times until it's back.

[ryzngard]

@liqube if it seems related to scale it might not be the fix from #43586

It's worth double-checking after this goes in that the issue is resolved. We're looking at 16.7 Preview 2 for the fix

[liqube]

@ryzngard will do!

and it doesn't seem like it's related to scale though. happens in any constellation of these two screens, with 100 and 125% scales, and even with one screen disconnected (restarting vs in between tests of course)

[SetTrend]

This issue not only happens on Edit.GoToDefinition.

I'm currently debugging a COBOL console application. Whenever the debugger closes the console window and automatically returns to the (opened) code file in Visual Studio, the cursor is hidden:

Microsoft Visual Studio Enterprise 2019
Version 16.5.5

[liqube]

This issue not only happens on Edit.GoToDefinition.

I'm currently debugging a COBOL console application. Whenever the debugger closes the console window and automatically returns to the (opened) code file in Visual Studio, the cursor is hidden:

Microsoft Visual Studio Enterprise 2019
Version 16.5.5

Again, I can confirm this happening with console applications. In my case a C++ console app. All third party extensions removed, still no luck.

[SetTrend]

@ryzngard : Could you please confirm whether your pull request also fixes the console project issue?

[StarTrekRedneck]

I can also confirm the issue presents when returning focus to VS from a completed console app. In my case, it's a C# console app project that merely does a Console.ReadLine(); hitting 'Enter' allows the application to complete, but when focus is returned to the C# text editor, the cursor is gone. I can evidently still move the invisible cursor around, Backspace, Tab, Enter, and navigation keys work, but character keys do not (for example, whereas I can delete existing text, I can't actually type anything new into the editor). Using the mouse to click back into the text editor returns normal functionality. [Visual Studio Professional 2019 Version 16.4.2]

[liqube]

I can also confirm the issue presents when returning focus to VS from a completed console app. In my case, it's a C# console app project that merely does a Console.ReadLine(); hitting 'Enter' allows the application to complete, but when focus is returned to the C# text editor, the cursor is gone. I can evidently still move the invisible cursor around, Backspace, Tab, Enter, and navigation keys work, but character keys do not (for example, whereas I can delete existing text, I can't actually type anything new into the editor). Using the mouse to click back into the text editor returns normal functionality. [Visual Studio Professional 2019 Version 16.4.2]

This perfectly sums it up.

[ryzngard]

@SetTrend this fix will only impact dotnet projects, so C++ and COBOL will not be impacted. Please file a separate issue as I believe they are not the same.

@StarTrekRedneck @liqube this will not be fixed by the solution here. This seems to be a more root issue than anything dotnet deals with, and by extension roslyn. It would be best to file another issue with repro using feedback for VS.

[SetTrend]

@ryzngard : Hi, Andrew. Done: #45043.

Cheers,
Axel

[george-tsiros]

maybe when VS reaches version 20 we will finally have a text editor that doesn't lose the caret.

but hey, we get pretty colors in regular expressions, right?

i'm not sorry, at this point ridicule and sarcasm i feel are appropriate.

[CyrusNajmabadi]

@george-tsiros I've hidden your comment for being offtopic and unhelpful. "Ridicule and sarcasm" are not appropriate or professional and go against the explicit code of conduct rules we have for this repo (and the dotnet org in general). Finally, as mentioned by Ryzngard, Roslyn has fixed the issue on our end. If you are experiencing this with other projects you will need to take it up with them. Investigations and fixes there would be out of our control. So venting here doesn't serve any sort of constructive purpose in terms of getting these issues actually addressed.

Thanks!

[george-tsiros]

i am not "venting"

your code is bad and you should feel bad.

On Mon, Jul 6, 2020, 11:24 CyrusNajmabadi [e-mail] wrote:

@george-tsiros https://github.com/george-tsiros I've hidden your
comment for being offtopic and unhelpful. Ridicule and sarcasm are not
professional and go against the explicit code of conduct rules we have for
this repo (and the dotnet org in general). Finally, as mentioned by
Ryzngard, Roslyn has fixed the issue on our end. If you are experiencing
this with other projects you will need to take it up with them.
Investigations and fixes there would be out of our control. So venting here
doesn't serve any sort of constructive purpose in terms of getting these
issues actually addressed.

Thanks!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/roslyn/issues/43585#issuecomment-654091140,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM77DI6IKW7NSP6KUMP7AVTR2GC4TANCNFSM4MOUN5ZA
.