DevTools hangs with high CPU usage when a breakpoint is hit while debugging my company's React code.

[gzx-miller]

Steps to reproduce:

1. Run my company's React project for debugging: npm run dev
   The service will run, and you can access it at http://localhost:80.

2. Modify the hosts file to map 127.0.0.1 to xxx.yyy.com.
   You can then access the above service by opening xxx.yyy.com.

3. In DevTools, locate the code and add any breakpoint that might be triggered. Then, trigger this breakpoint through an operation.
   You will see that the breakpoint is effective.

4. For the first 1-2 seconds, DevTools is still responsive, but after that, it becomes unresponsive. You can't switch tabs or inspect variables in the call stack. Additionally, you can see that its CPU usage spikes, consuming an entire CPU core. If you resize the DevTools window, the newly exposed part of the window isn't rendered.

5. If you choose to close DevTools, the program resumes normal operation.

About the Edge version:
This issue did not exist in the initial version 122 of Edge. The problem appeared after I upgraded WebView2 from version 122 to 127.
I consulted with some friends at Microsoft, and they asked if the same issue occurred in Edge. At that time, my Edge version was 122, and I couldn't reproduce the issue. So, I upgraded Edge to version 127, and the problem appeared, just as it did with WebView2 version 127.

About the reproduction rate:
In my code environment, the issue has a high reproduction rate, around 90%.
I tried to reproduce the issue in a simple React project, but I couldn't.
It may require a more complex React project, and it should be running in a React debug service environment.
Unfortunately, I cannot provide my company's code, as it's not allowed to be shared.

Screen from edge devtools:

AB#53420578

[captainbrosset]

Thank you for filing. I will make sure this shows up on our dev team's backlog.

[robpaveza]

Hi @gzx-miller , I'm Rob Paveza, an Engineering Manager on the DevTools team.

Without knowing a lot about your project, I wanted to ask about one case in which we've often seen this. Is your build system configured to use something like eval-source-map or cheap-eval-source-map as the source map configuration?

Some background: some build systems like Webpack provide this as a mechanism to support Hot Module Replacement. In short, suppose you have a single TypeScript file like this:

export function add(a: number, b: number): number {
  return a + b;
}

A conventional way to bundle and minify this might look like this:

export const add=(a,b)=>a+b;

Setting aside the issue of minification, what ends up happening to support HMR with eval is something like this:

eval(`function add(a, b) { return a + b; }
  return { add };
`);

That is approximately semantically equivalent modulo ES modules behavior, and it allows the module to be swapped at runtime by changing the object representing the module.

But this produces a terrible debugging experience. So the folks who did that added source maps to it:

eval(`function add(a, b) { return a + b; }
  return { add };
// #sourceMappingURL=data:text/json;base64,ej...
`);
// #sourceMappingURL=data:text/json;base64,ej...

So now you see that the source map is base-64 encoded JSON text encoded inline twice: once within the module itself, and another time within the eval. (I have quite literally seen this.) The source maps are actually germane, as well, because they represent two different scripts: the script containing the eval, in which the interior script is just a string; and the eval'd script itself. But the net result is that for each bundle (and each time the modules are hot-reloaded), you have 4 copies of the source code being handled within the script engine.

I'm not saying that this is causing your issue -- however, I have seen from an internal team that this can cause quite a bit of CPU thrashing and performance degradation. (I also saw OOM crashes from this). It is a severe problem with the HMR mechanism for large projects, so if possible, I'd like to eliminate this as a cause.

[gzx-miller]

Hi, @robpaveza ,
Thank you for your response!

It might indeed be the cause, as I have found code related to evalSourceMap in the project:

//webpackDevServer.config.js
const evalSourceMapMiddleware = require('react-dev-utils/evalSourceMapMiddleware');
devServer.app.use(evalSourceMapMiddleware(devServer));

However, what methods can I use to bypass or fix this issue?
I have tried remove those code in webpackDevServer.config.js, but the problem still exists.
Currently, this problem is somewhat hindering common debugging work.
Many issues that could usually be inspected by setting breakpoints now require investigation through added logging.

The last question is "Why chrom and edge122 without problem?"

[gzx-miller]

I recently found that a necessary operation to trigger this phenomenon is, after hitting a breakpoint, hovering the mouse over the variable to observe its value, which will cause a hang and high CPU usage. However, as long as the variable is not inspected, I can step through the code multiple times fluently. @robpaveza @captainbrosset

[wertzui]

I have the same issue since some time.
I'm currently on Version 132.0.2926.0 (Offizielles Build) canary (64-Bit)

[HesamKashefi]

My browser hangs on breakpoint too.
This issue has been around for a couple of months.
I have tested on 3 different computers (one of them is a high-end PC).
My code is an angular application.
On the other browsers there is no problem. (Chrome, Firefox).

[leahmsft]

Thank you all for the details about this issue. I'll bring this back to the engineering team to help investigate.

[nvdweem]

Same issue here, also with an Angular application, also noticed it for several months.
Running in incognito without any plugins enabled doesn't help.

I did notice that disabling javascript sourcemaps also removes the hang (mostly, it then needs to highlight a huge file but that's way faster still), but disabling sourcemaps alltogether isn't really an option.

[leahmsft]

@gzx-miller @wertzui @HesamKashefi @nvdweem
Hi all,

Can you please provide the following details to assist the engineering team's investigation:

• Environment: OS, Edge browser version (can be found at edge://settings/help)
• Steps to reproduce the behavior
• Any additional context that's relevant

[wertzui]

Windows
Edition Windows 11 Pro Insider Preview
Version Dev
Build 27744.1000
Funktionspaket Windows Feature Experience Pack 1000.26100.32.0

Edge
Version 132.0.2941.0 (Offizielles Build) canary (64-Bit)

How to reproduce:

• Open developer tools
• Add a breakpoint that will be hit
• Hit the brakpoint
• Try to interact with the dev tools and see that they froze for a minute or so

[HesamKashefi]

I think I fixed it!
I just removed all the extensions and tested again.
Everything looks fine now!
Then I installed Angular DevTools and Redux DevTools again. It became slow again but hangs just a about five seconds not like before which was about 1 minute!
Here's a list of my extensions before I removed them.

My Edge version is : Version 130.0.2849.80 (Official build) (64-bit)
My Windows version: Windows 11 23h2 22631.4460

In the past even when I disabled all the extension nothing was different but now that I removed all and just install Angular and Redux DevTools when I disable them, everything is superfast.

It was really annoying to have such hang duration (1 Minute) on an Intel Core I7 14700K - 32G RAM DDR5 - SAMSUNG 990Pro M2 - ....

[nvdweem]

Can you please provide the following details to assist the engineering team's investigation:

• Environment: OS, Edge browser version (can be found at edge://settings/help)
  • Edition Windows 11 Pro
  • Version 23H2
  • OS build 22631.4460
  • Experience Windows Feature Experience Pack 1000.22700.1047.0
  • Edge: Version 130.0.2849.80 (Official build) (64-bit)
• Steps to reproduce the behavior
  • Seems to be project size dependant, my work project can hang for tens of seconds, a new project hangs for up to 10s
  • See steps below
• Any additional context that's relevant (not sure how to tell what's relevant)
  • My work project uses the old webpack builder, a new project should be using the esbuild builder, both seem to trigger the issue
  • It has been happening for months
  • Also happens in incognito (perhaps even more deterministic)
    • I don't have the Angular Devtools extension installed, so that one isn't the cause for me
  • It seems to be worse the first time it hits a breakpoint, after waiting once, the rest of the hits are usually quick

Steps to reproduce

1. Install Angular (I'm running 18.2.12 myself)
2. ng new SlowApp
3. Not sure if it matters, but I tend to pick scss and disable ssr
4. ng s
5. Change src/app.component.ts, add ngOnInit() { debugger; } in the class
6. Open an Incognito tab
7. Open Dev Tools (F12)
8. Navigate to http://localhost:4200 (this will hit the breakpoint immediately)
9. Notice that it takes up to 10s before you are able to select text in the sources tab

[leahmsft]

@HesamKashefi glad to see that you found a fix and it's working again!

@wertzui are you also seeing this with Angular or just in general?

@nvdweem can you try the same fix @HesamKashefi mentioned above and report back if it worked for you too?

[nvdweem]

@nvdweem can you try the same fix @HesamKashefi mentioned above and report back if it worked for you too?

I had seen that workaround, that's why I included

I don't have the Angular Devtools extension installed, so that one isn't the cause for me

And

Also happens in incognito (perhaps even more deterministic)

In incognito, no plugins are enabled, so sadly the workaround doesn't work for me.

[leahmsft]

@nvdweem apologies for missing that. A new version of Edge Stable recently shipped to v131. I noticed that you're seeing this bug on v130. Have you tried updating to the most recent version?

[nvdweem]

I think my Edge updated right after posting the version (Version 131.0.2903.51 (Official build) (64-bit)) and I think I've seen the issue pop up afterwards, but I'm not entirely sure. It doesn't always trigger, but just tried a few breakpoints in and outside of InPrivate and those seemed to be interactive quite quickly.

I'll try to pay attention to whether it triggers again in the coming days.

Update: immediately after this message I hit a breakpoint that took ~15 seconds to become responsive again, refreshing the page and triggering it again 'only' takes ~3 seconds.

[HesamKashefi]

@nvdweem I removed all of the extensions, they were already disabled when I had the issue. maybe you could try this too.

I'm guessing that maybe it's from installing extensions 'from other sources'

[nvdweem]

@nvdweem I removed all of the extensions, they were already disabled when I had the issue. maybe you could try this too.

Also tried it with a new profile, not a single extension installed (other than a disabled Offline Google Docs extension that was already there). The first breakpoint I hit took about 10s to become responsive, the next one was instantly responsive. A breakpoint a few moments later took ~5s to become responsive. Triggering the same breakpoint in my regular profile also takes about 5s.
It's way faster for these two occurrences as compared to my actual profile in the 130 version, 5s is still a long time to wait on nothing, but more of a nuisance than flow-breaking like the 30s+ delays that I've seen before.

Having following breakpoints trigger quickly feels like a cache miss on the slow triggers. I'll have to pay some more attention, but it could be that breakpoints after code-changes are slower because something (map files?) need to be reparsed or something.

If disabled plugins do anything then that sounds like a way bigger problem than just unresponsive breakpoints.

Edit: Tried the same breakpoint in the blank profile as a slow breakpoint in my regular profile when it was slow and it seems that the blank profile stays pretty quick.