Change:
Issue Type: <bBug</bI've been seeing this a lot relatively recently (several weeks at least, probably months); although it's intermittent, it happens frequently. I've reproduced it with all extensions disabled. Sometimes when I invoke vscode from in windows (vscode is already running), when vscode comes to the foreground, it doesn't open the requested file, and it's stuck. As soon as I send it down and bring it back up again (alt-tab) the file opens and vscode is fine. It's gotten pretty tedious. I'm invoking code through 2 layers of .cmd files, although I don't think this has anything to do with it. e.cmd: and c.cmd: VS Code version: Code 1.61.2 (, 2021-10-19T14:57:20.575Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </detailsExtensions disabled<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
e.cmd: It might not have anything to do with it but it could and so I would suggest to see if you can reproduce this without that indirection.
Can you also add the flag to the launch options and see if the issue happens.
Bypassed extra .cmd files by copying "official" to e.cmd and adding "%~dp0.." "%~dp0..resourcesappout" --disable-features=CalculateNativeWinOcclusion % receiving message Warning: 'disable-features' is not in the list of known options, but still passed to Electron/Chromium. on startup
I haven't seen this at all since I made these changes until this afternoon - and it turns out an update that installed today had clobbered the tweaked e.cmd in the vscode/bin. Seems like a good argument for these changes being successful for me. So, it's one or more of: eliminating extra .cmd indirection for startup (seems unlikely) (probable) the message being written to the console may change the timing or something (could be?) Reinstalled my tweaked e.cmd outside of the vscode/bin, and I'll let you know if it happens again.
Verified I am still able to reproduce this even with the changes above. It seems like it's more likely to occur if vscode is completely covered before I bring it forward(?). At the moment, I'm getting it pretty consistently, not every time but pretty regularly, when covering vscode with chrome or firefox. All windows fully maximized on the same monitor.
Based on the description, this is definitely a side effect of the occlusion tracker, can you share a screen recording of the behavior you see and the arguments used to launch vscode. Thanks! /gifPlease
To be clear: this is still occurring with , although it's possible that it's less frequent. The other day I could get it to happen pretty consistently, today, not so much. My software has updated since the original report, currently running: I don't think this would be an uncommon problem, since there's nothing unusual about my environment. Maybe my usage habits are atypical - I'm often typing into a separate terminal window ( or under windows terminal both have the same behavior) and invoking vscode from there, opening files from the command line. I'm currently using the following e.cmd file, having removed the cmd layers mentioned previously: If I can get it to happen semi-regularly again, I will attempt to get a screen recording, but I can tell you what it will show: me typing "e " into a command window, where vscode prints "Warning: 'disable-features' is not in the list of known options, but still passed to Electron/Chromium.", then vscode comes to the front and doesn't have keyboard focus (and is not responsive to the mouse). I can't see what a screen recording will add to that. So far I haven't found any magic that causes it to happen or not happen.
I had recently removed the and the problem started happening again. It's possible that the time I was able to reproduce it with present I had removed it and it back in, but hadn't exited all running copies? I will remove the again just to be sure.
After removing I am seeing the problem again occasionally. One difference to note is that it appears that the window will go out to lunch for ~10 or 15 seconds, but eventually become functional again. I hadn't noticed this before - I'd always had to demote and promote the window to get it back. Currently running
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Actually this fix is in the latest stable too so that could be used as well.
I'd removed the from my startup script in September 2022 based on . Haven't seen this behavior in a long time.

Discussion:
} }); <ins> /* Following features are disabled from the runtime. * `CalculateNativeWinOcclusion` - Disable native window occlusion tracker, *	Refs https://groups.google.com/a/chromium.org/g/embedder-dev/c/ZF3uHHyWLKw/m/VDN2hDXMAAAJ */ app.commandLine.appendSwitch('disable-features', 'CalculateNativeWinOcclusion'); </ins> // Support JS Flags const jsFlags = getJSFlags(cliArgs); if (jsFlags) {