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