Vscode: External dialogs appear behind VSCode

Created on 29 Jan 2018  路  17Comments  路  Source: microsoft/vscode

  • VSCode Version: Code 1.19.2 (490ef761b76b3f3b3832eff7a588aac891e5fe80, 2018-01-10T15:55:03.538Z)
  • OS Version: Windows_NT x64 10.0.16299
  • Extensions:

Extension|Author (truncated)|Version
---|---|---
csharp|ms-|1.13.1
PowerShell|ms-|1.5.1


Steps to Reproduce:

With the AzureRM powershell module:

  1. in the default powershell terminal run: Login-AzureRmAccount
  2. Notice the dialog appear behind VSCode:
    image


Reproduces without extensions: Yes

I'm also curious if there's a way for an extension like the PowerShell extension for VSCode to bring UI to the top, over VSCode. Often UI generated by other programs (debug extension, user programs) show up behind VSCode and it confuses users (causes bug submissions).

This issue was sparked by:
https://github.com/PowerShell/vscode-powershell/issues/1175

electron upstream upstream-issue-linked windows

Most helpful comment

I still find this very annoying every time I use VS Code - just bad user experience in the tool.
I appreciate that it is probably caused by issues spread across different teams/code at Microsoft, but I'm looking forward to the day someone at Microsoft finally takes ownership of it and deals with it.

All 17 comments

Reading your description it seems that the issue originates from an extension and not VS Code itself. Thereby I will close this issue and kindly ask you to report this issue against the extension repository.

Most extensions are on GitHub as well so it should be easy to file it against the extension. If you open an extension on the market place, click on the Support link to find out more.

screen shot 2016-05-05 at 12 51 17

Thanks again for your feedback!

This was closed by mistake it would seem.

I stated in my repro steps:
"In the default powershell terminal". In other words, the one that ships with VSCode itself.

I was also just curious from an extension standpoint. That part is more of an aside to the actual issue.

Looks like this is related to electron, I haven't experienced the issue personally.

@Tyriar here's an easier repro that doesn't require the Azure cmdlets.

Get-Process | Out-GridView

Can you repro that?

Note: that will only work on Windows and with Windows PowerShell.

Yes I can repro with that, thanks. I still think it's an Electron issue though

Some observations:

  • Opening an external link from the release notes editor opens Edge in front.
  • Opening the device login from the Azure Account extension opens Edge in front.
  • Opening a link (Start-Process "http://www.microsoft.com/") from PowerShell in the integrated terminal opens Edge behind.
  • Opening a link (Start-Process "http://www.microsoft.com/") from PowerShell in the external terminal opens Edge in front.

I have managed to find these Electron issues that sound related, but not completely sure:

https://github.com/electron/electron/issues/11989

https://github.com/electron/electron/issues/6081

Hi,
I found a lot of threads about the same issue, most of them is closed as related/duplicated issues but nothing what could explain/help or tell what to do and where is the problem. I have newly installed VS Code with powershell extension and observe same issue no matter if I run "login-azurermaccount" or "Get-Process | Out-GridView" all windows which should appear in new window are in the background. In Powershell ISE it works without any issues.

VS Code:
Version: 1.30.2 (user setup)
Commit: 61122f88f0bf01e2ac16bdb9e1bc4571755f5bd8
Date: 2019-01-07T22:54:13.295Z
Electron: 2.0.12
Chrome: 61.0.3163.100
Node.js: 8.9.3
V8: 6.1.534.41
OS: Windows_NT x64 10.0.17763

Extension:
powershell extension: 1.11.0

PC:
windows 10 ver. 1809 build 17763.253

Please, could somebody help?

Thank you.

looks like electron also passed on owning this issue - they refer to using forcefocus as a workaround.

It does seem to be a hard problem, but from a user experience perspective we could do better - maybe we can consider using forcefocus in vscode for this use case. If this is your first user experience with vscode like @cbailiss - you are less likely to continue using the editor and shell as it doesn't work.

Just wanted to pass along @alohaninja's comment in https://github.com/PowerShell/vscode-powershell/issues/621#issuecomment-479769873

As it seems like this will have to be addressed by vscode.

This is problematic for beginners on vscode. I transitioned from the ISE to VS Code and experienced this. I wasted 30 mins trying to figure it out. Now multiply that amount of wasted time by the number of new VS Code users using the product simply for the PowerShell extension because Microsoft deprecated the PowerShell ISE. That's a lot of wasted time.

I still find this very annoying every time I use VS Code - just bad user experience in the tool.
I appreciate that it is probably caused by issues spread across different teams/code at Microsoft, but I'm looking forward to the day someone at Microsoft finally takes ownership of it and deals with it.

@Tyriar This is a ConPTY issue, not Electron: microsoft/terminal#2988

It鈥檚 the same underlying issue as in #929, #13255. The powershell process doesn鈥檛 have permission to change the foreground window.

Using the-ress/node-windows-foreground-love isn鈥檛 practical in this case - the permission gets revoked after next key press or mouse click.

Windows console handles this by using undocumented API, but there鈥檚 not an equivalent documented functionality for ConPTY (as far as I can tell).

@DustinCampbell any advice on what we should do? microsoft/terminal is using private APIs apparently to force launched apps to the foreground https://github.com/microsoft/vscode/issues/42356#issuecomment-552153955

Meant to ping @DHowett-MSFT

@Tyriar I'm somewhat affronted at your assertion that Terminal is using a private API we wouldn't expose to anybody else.

There's no magic here. It just luckily works out for Terminal sometimes. It's being tracked by https://github.com/microsoft/terminal/issues/2988, and there's really no good solution for us _or_ for you. PowerShell cmdlets need to not have a dependency on the window they're hosted in, because that will fail for all remoting scenarios and all SSH/telnet/multi-tenant scenarios too.

(EDIT: I was affronted, but then I read the rest of the conversation.)

Reading up a few move comments:

@the-ress The snippet you identified here serves a totally different purpose: it marks the application that spawned the console window as _owning_ the console window. This makes things like task manager and process explorer able to map from a HWND to _cmd.exe_ or _powershell.exe_.

That code isn't included in the Terminal application. :smile:

PowerShell cmdlets need to not have a dependency on the window they're hosted in, because that will fail for all remoting scenarios and all SSH/telnet/multi-tenant scenarios too.

@DHowett-MSFT Totally agree... but considering so many PowerShell customers have relied on:

  • Out-GridView for visualizing data/manually filtering a pipeline
  • WinForms & WPF (to a point where they've made tooling around it: https://poshgui.com/)
  • Some Azure PowerShell cmdlets still pop a GUI... and people run into it.

Unfortunately, this type of practice isn't going to stop any time soon.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

VitorLuizC picture VitorLuizC  路  3Comments

borekb picture borekb  路  3Comments

mrkiley picture mrkiley  路  3Comments

biij5698 picture biij5698  路  3Comments

omidgolparvar picture omidgolparvar  路  3Comments