LSP window/showDocument{external=false, takeFocus=true} does not raise the editor window

[adonovan]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.87.2
• OS Version: macOS 14.3.1

Steps to Reproduce:

1. From an LSP server, send a showDocument request with a file: URL, external=false, takeFocus=true. Do this while another window is on top of VS Code.
2. Observe that, although VS Code opens the designated file and navigates to the correct line and column, it does not raise the window, making it potentially impossible for the user to notice that anything happened at all.

Why do I care?, you might ask. We (the maintainers of the Go LSP server) are using a web server within our LSP server to display reports in response to certain queries initiated by the editor via a Code Action. A report might be rendered documentation for the current package, for example, or a rendered CPU profile. The reports contain links to the source code, that, when clicked, cause the LSP server to send an asynchronous showDocument downcall to the editor, causing it to open the designated source location. This enables very rich interactions between the editor and the browser.

[vscodenpa]

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.87.2. Please try upgrading to the latest version and checking whether this issue remains.

Happy Coding!

[dbaeumer]

Actually takeFocus is supposed to take focus inside the editor not bring the editor to front.

I also tested this with pure VS Code API and it has the same behviour.

I will close the issue since it IMO works as expected.

[adonovan]

Actually takeFocus is supposed to take focus inside the editor not bring the editor to front.

I wonder what is the value of taking focus if the editor window is not visible; and what is the cost of raising the window when responding to a showDocument request.

[adonovan]

An alternative:

If changing the default behavior of showDocument is unacceptable (is it?), could we add a raiseWindow option? The server would set it for requests initiated asynchronously, that is, not in response to an editor interaction but in response to an external event such as an interaction in the browser window I mentioned above. If that makes sense, let's repurpose this issue as a feature request.

[dbaeumer]

I wonder what is the value of taking focus if the editor window is not visible;

It gives focus so that when you bring the window to front the editor has the focus.

raiseWindow > I am not a fan of such an API especially not from a server that does that un-related to a use action.

Before adding such a API to LSP we would need it in VS Code first. So I suggest to create a new issue requesting such a feature in the VS Code API and we take it from there.

[adonovan]

raiseWindow > I am not a fan of such an API especially not from a server that does that un-related to a use action.'

It's particularly when the showDocument request arrives outside of the context of an active client-to-server call that raising the window becomes necessary; for all other showDocument requests we can rely on the editor being visible since the user must have just interacted with it.

(BTW, we've been thinking of using this kind of out-of-band browser request as a means to portably prototype refactorings
that require some kind of dialog or interaction, in effect a workaround for the lack of LSP dialog support as described in microsoft/language-server-protocol#1164. We would display an HTML form in the browser with all the options to the refactoring, and arrange for the form's submit button to cause the server to send an ApplyEdits downcall to the client. If LSP dialogs appear later, we can use that instead, but of course that requires support in N editors.)

Before adding such a API to LSP we would need it in VS Code first. So I suggest to create a new issue requesting such a feature in the VS Code API and we take it from there.

Thanks for the advice; will do.