Change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --- VS Code Version: 1.56.0 OS Version: Windows_NT x64 10.0. Steps to Reproduce: breakpoint in js.-file debug-session in browser (all breakpoints in dev-mode disabled) to browser window browser (because it is just half open) breakpoint blinks in taskbar -switch back to it freezes and waits for something Hints: By avoiding step 4, this issue doesn't occur. Minimizing and maximizing VSCode while its freezed solves this issue. This issue also happens in insider-version of VSCode. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Launch configuration (no, this problem is not related to brave, it happens also in google chrome):
This looks like a regression of the issue mentioned in , , and others and declared a duplicate of . It was fixed in 1.55 but it's back. Super annoying.
First breakpoint successful, then I triggered it again with no success.
can you reproduce if you start vscode with
With this issue does not occur. I tested it with several sizes of the browser-window (see initial text) and the breakpoint got hit instantly. Additonal information: CMD says "Warning: 'disable-features' is not in the list of known options, but still passed to Electron/Chromium."
lovely thanks a lot. This happens only on Windows, thus assigning flag, and it seems to be electron related thus assigning to my friend We will investigate if we can fix this as part of the recovery release. If not we plan to fix it in the future
probably not related, but just to be 100% sure if you put In your settings, can you reproduce? WORKAROUND Put in your settings
With I can reproduce the issue. With (as the command says) VSCode window does not focus, but breakpoint got hit successfully.
thanks, but if the windows does not get focus there is no freeze? As for the setting that is something which we changed this milestone and I just wanted to verify it is not related to this issue.
Yes, there is no freeze. The icon in the taskbar is also not blinking.
Latest insiders has a workaround in place, you can launch vscode without the commandline flag to verify. I will keep this issue open however to investigate the root issue in the runtime.
Unassigning myself. Let me know if I can help somehow though
This happens with also. I suppose it's not going to be fixed in May 2021 release?
This will be fixed in the May release, the issue is open to eliminate the workaround we have set.
The latest insiders has updated runtime that does not contain any workaround for this issue. Can anyone check if the issue is present ? Thanks! closedWith
/verified
Per the linked issue this still seems to happen
Same here, was in vacation, did an update of VS Code when I returned and now I have this bug too. Never had this before. Switching to another Windows in the Task Bar and back, makes Debugger working again.
Matt reported this on OSX
Yup that is definitely unrelated, as this occlusion tracker is specific to windows only. Tracking it here , currently waiting on logs to understand better.
If I may note again as I did in a related thread, this problem is symptomatic of an unmatched  pair - hopefully this might offer a clue.
I have the same issue with VS Code 1.60.1 and Windows 10 build . A working workaround is setting , as mentioned. I also saw that if I grab the VS Code window by the title bar and then maximize it by dragging it to the top of the screen, it unfreezes instantly. Please fix this, it's so annoying. Thank you.
I hit this all the time just opening any file. I am not debugging.
Hello everyone, I've confirmed the flag works well indeed, but is there a way to use this flag everytime I open a VS Code window? I tried to add this line into the file: but it didn't work. Actually I did not expect this to work because it is clearly stated at the top of the file that I also tried to add flag into the file as an argument. It works if I launch the VS Code from the terminal using , but it doesn't work when I launch the VS Code from the File Explorer context menu. I also the same flag to these keys from the regedit: HKEYCURRENTUSERSOFTWAREClassesDirectoryBackgroundshellVSCodecommand HKEYCURRENTUSERSOFTWAREClassesDirectoryshellVSCodecommand These changes make sure to have the CLI flag everytime I open VS Code, but I'm pretty sure those will be overridden with the updates. Even if they're not, I'd be happier if I can set the flag from one place to everywhere. Is this possible somehow? Thanks in advance for any help!
Any update? Thanks
Still have this on Windows 10 and latest VSCode version. Annoying :(
I can confirm that this behavior still exists. It's very annoying because, at least me, need to check if I did something wrong while debugging and then switch multiple windows to finally have the visible breakpoint in VS Code.
I am still having this issue too, on Windows 10 with the code running inside WSL2. I'm using the workaround, which is not perfect but ok. If it can help, I noted that without , if you click on any open editor and then click on the editor containing the target breakpoint, then the breakpoint hits almost immediately... But that sucks because you need to know what editor to click, it doesn't show up automatically. Using the is another trick to know where the hitted breakpoint is. But those are all workarounds looking for a real solution.
The latest version of Chrome browser has a similar phenomenon. I think this is Chromium's problem.
I think the issues reported here don't have much to do with the problems I reported in because they only started with VSCode 1.66 and I haven't noticed any of that before.
This issue has been open for over a year now. Has there been any progress on fixing this bug? Is there an ETA? Has the root cause for the bug even been identified yet? I'd prefer not to add a launch flag, because I'm likely to forget to remove it once it eventually gets fixed. This issue still happens for me on Windows 11 with all the latest updates. It also happens when I simply leave the computer unattended for a while. VSCode hangs and takes ~30s to respond to input again. Same thing happens with certain pages opened in Chrome.
I am coming from issue . If this is the same root cause, then it is not restricted to Windows. I am on Arch Linux with Sway WM: I can confirm the bug there as well, that after switching focus from another application back to VSCode, it takes between 1-3s until VSCode becomes responsive again. I am happy to help debug, if need be.
Solution here:
This issue still occur for v1.68.1
Have you tried uninstalling completely and doing a clean install as I described here? The problem is the cache growing to several thousands of files from the initial few hundred. So VSCode slows down to a crawl trying to process all of that.
This is no real solution, but a temporary fix. VSCode must be fixed for the real solution
Well, it's the ONLY solution that I could find after many months of searching and trying everything possible and impossible. The interesting thing is that when I mentioned this solution/workaround/temporary fix (call it as you wish), the thread was promptly locked up: Seems like someone is trying to sweep the issue under the proverbial rug...
I try to avoid when I start moving the code window (as suggested by others), the breakpoint appear. So I believe nothing to do with the cache sizes.
Then I also realize that sometime I don't even need to move the window, the break point response that is intermittent
For now, I try not to do anything so that when there is a fix, I have a broken vscode to prove this fix is working.
There is a workaround on disabling this option in VS Code Settings. By doing this u have to live with the fact that the VS Code icon will not blink in the taskbar when the debugger hits a breakpoint But the Window will also not freeze !
I have opened a performance issue via code and attached a performance profile as well, since I got hit by this bug multiple times today. I am on Linux.

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) {