Symbols in Monaco stop to be recognized and cannot be navigated to

[eneufeld]

Bug Description:

Steps to Reproduce:

1. Code in Theia and navigate to the definition of a symbol using ctrl+click (ideally defined outside the current file)
2. use the back navigation to go back to the file you came from
3. try to navigate to the symbol again

Unfortunately this is not 100% guaranteed to lead to the issue. You have sometime to navigate to multiple different symbols and go back and forth. After some time symbols cannot be navigated to anymore.

Additional Information

• Operating System: Ubuntu 22.04.5
• Theia Version: 1.58.100

[sdirix]

I can reproduce the issue, I can not even select anything in the line anymore

Reproduction steps:

• Open preference-string-input.ts
• Make the editor permanent (double click title bar)
• Follow the PreferenceLeafNodeRenderer interface via Ctrl+Click
• Switch back to preference-string-input.ts
• Observe that
  • The followed line can no longer be selected
  • The hover popups for the line no longer work
  • Navigation (Ctrl+Click) also stops working
• To workaround the issue, close and reopen the file

[tsmaeder]

Thanks @sdirix

[tsmaeder]

I can reproduce the problem, but only on Linux

[tsmaeder]

Very strange: the cached line width in viewLine.ts#getWidth() for the line is 0, so you can select on this line, but you always end up with an empty selection at the end of the line, because that's the behaviour when you click after the end of the line (which the editor thinks is the case).

[tsmaeder]

The trouble seems to be that the editor is being rendered when it is already not visible anymore. The offsetWidth at this time is 0, as would be expected of an element that is below on that has display: none set. Not sure why this would start being an issue now nor why it only affects one line.

[tsmaeder]

Well, it kinda makes sense, since it's the only line that needs to be re-rendered: when I -hover over the line, the text is underlined, when I click the link, the text goes back to non-underlined and needs to be re-rendered. All other lines keep their cached content and therefore width.

[tsmaeder]

When I look at the html structure in VS Code, I only ever see a single dom tree in the editor area when I switch between editors. So it seems as if they don't hide invisible editors, they just replace the editor in the dom with a new one. That would explain why this does not happen in VS Code. As for why it only happens on Linux: the recalculation of line widths happens with a delay of 200ms. If it takes longer that 200ms to hide the editor dom node when navigating, the old editor dom is still visible and the update of the width succeeds.

[tsmaeder]

I'm trying an approach where I set the model on the StandaloneCodeEditor to null when hidden and restore it when revealed.

[tsmaeder]

Looks like the approach fixes the problem. Now I just have to make sure the necessary view state (like scroll position, selection) is preserved and restored appropriately.

[tsmaeder]

Got the selection, etc. to restore properly, but now <ctrl><space> is broken when moving back. Needs more debugging.

[tsmaeder]

Seems like the focus is not restored properly when revealing the editor. Invoking focus() on the ICodeEditor fixes the problem. I'd like to understand why the focus is not set properly, though. Also need to think about whether setting the focus on reveal might have unintended side effects.