Blazor wasm hot reload constantly hitting internal JS breakpoints when the browser dev tools are open

[Stuart88]

I'm almost certain this isn't actually a bug - surely I have just got something set incorrectly - but it has plagued my Blazor debug experience since the earliest days of Blazor right up until now.

With browser dev tools open, any time a hot reload completes, there is an unbearable stop/start jittery mess of constantly hitting an internal debugger breakpoint within the framework scripts.

This part to be precise:

in the file debug.ts and the function is mono_wasm_fire_debugger_agent_message_with_data_to_pause.

The dev tools even has a message saying "This script is on the debugger's ignore list" so there isn't much more I feel I can do within my browser settings. It must be something relating to blazor debugging and/or how it interacts with Visual Studio.

Does anyone know how can I stop this from happening?

Thanks

[bzd3y]

If you are using Visual Studio, go to Tools > Options and then search for "new mono". In the filtered results there will be an item named "Enable new .NET 9+ Mono debugger for WASM apps" that is probably checked/enabled. Uncheck that.

The actual path to this setting is just "All Settings / Preview Features".

[bzd3y]

Something else is going on then, which, well, sounds like the standard experience.

Are you sure it isn't re-enabled? For example, I just did a repair of Visual Studio so I could actually just run my project. But that repair re-enabled that setting for me.

[Stuart88]

I've tried with it enabled and disabled alternately and the issue is the same always.

I'm not sure any VS repair will help me here as the experience was the same for me always, on VS2022 and VS2026.

[bzd3y]

I don't know how much it helps, but when I ran my project in VS Code it didn't have this issue. It wasn't ideal for a number of reasons, but it was better than not being able to debug at all.

I'm not sure any VS repair will help me here as the experience was the same for me always, on VS2022 and VS2026.

Well, I was just saying you should go back and make sure that setting is still disabled because it is possible for it to be re-enabled and you might not realize it.

If you did check and it is still disabled then I don't know what to tell you, at least not that would be productive.

I don't remember this ever happening for me in VS 2022, but that makes me wonder if maybe you have some old components that could be uninstalled? Or that maybe a repair would actually fix?

But sorry I can't be of much more help. Disabling that setting definitely fixed this for me.

If you dig deeper and see what kind version of the debugger you are using, that might help people here troubleshoot. Especially if you don't have the problem in VS Code. They use separate debuggers.

[Stuart88]

I just tried again with the mono debugger re-disabled.

On my home page, hot reload worked without any flickering through debugger breakpoints in dev tools. Woohoo! I think?

But on another page it went back to the flickering. The only possible difference I can find is that the home page is InteractiveAuto, and the flickering page is InteractiveWebAssembly.

Either way, seems like a bug or something broken something.

[bzd3y]

My experience is similar, with only some pages doing it. I only noticed it on pages that had a Syncfusion grid on them. As far as I know, all of my render modes are the same, and whatever the default is.

I wouldn't be surprised if the RenderMode did make it behave differently.

[MukundaKatta]

[bzd3y]

Thanks @MukundaKatta, this is great information. That confirms my gut instinct, which was that this was more of a "problem" with the browser, not VS or the debugger itself.

However, the pattern does not seem to work in Edge. I have "Ignore listing" checked which seems to be the equivalent of the "Skip debugger; statements in ignored scripts" setting you mentioned. But the statement still gets hit.

With that being said, and this is more for the aspnetcore team, I wonder if one or more is possible on the debugger side:

• configure this in the debugger's browser profile
• configure it through the "inspectUri" in launchSettings.json
• configure it through command line options when the browser is launched

[bzd3y]

@Stuart88 Lol, so I'm not the only one that gets frustrated with that. I'm not sure that was AI, though. What is flagging it that way for you? I haven't really used any AI services, so I might just have trouble identifying it sometimes.

[MukundaKatta]

Fair hit, @Stuart88 — apologies for the AI-tone on that comment. I'll be more careful.

On your actual finding though, the InteractiveAuto vs InteractiveWebAssembly split is a useful signal: Auto renders server-side first and only hydrates to WASM after, so the Mono debugger agent isn't in the picture for the initial paint. If the flicker is reliably pure-WebAssembly only, it's worth its own issue with that repro — likely a different code path than the setting toggle addresses.

[Stuart88]

@MukundaKatta I mean this in the kindest possible way: Fuck off with the additional AI replies.

@bzd3y I can tell it's AI because firstly the content uses those long em dashes ( — ) which you can't type on a standard keyboard. Secondly, the wording is woefully unnatural, e.g. "If the flicker is reliably pure-WebAssembly only" nobody writes like that. Also the main large reply from earlier is written like a fucking blog post..,. for a random little discussion on github. With titles like "Why this happens at all" and "Skip debugger; for the whole framework bundle" (that whole section is grotesquely "AI"). For a tiny github discussion it sure does seem weird to have our hero @MukundaKatta wading in with big authoritative blog post replies.

This discussion is ruined. I detest lazy misuse of AI.

[bzd3y]

@MukundaKatta I don't see that setting in either Edge or Chrome. The confident incorrectness does seem somewhat AI-ish. Also, I tried Googling the title of that setting and Google seems to know nothing about it.

@Stuart88 Okay, but you're being pretty hostile to somebody who is trying to help you, albeit not very successfully. I get where you are coming from with the em dashes and other formatting, but I figured there was a good chance that was just because it got copied from somewhere else. I'd just be careful, because if you look at my comment history on here, I tend to make pretty long posts/comments sometimes. Some people are just verbose. Also keep in mind that if there is a human behind that account then they might not speak English fluently and might be using AI to translate their message into English.

But to be honest, it's refreshing to see that I'm not the only one that gets mad about overly used AI.