[release/7.0][wasm][debugger] Support new feature on browser: instrumentation pause #82854
Conversation
|
Tagging subscribers to this area: @thaystg Issue Detailsnull
|
thaystg
changed the title
|
/backport to release/6.0 |
|
Started backporting to release/6.0: https://github.com/dotnet/runtime/actions/runs/4307867498 |
|
@thaystg backporting to release/6.0 failed, the patch most likely resulted in conflicts: $ git am --3way --ignore-whitespace --keep-non-patch changes.patch
Applying: backport of 82852
Using index info to reconstruct a base tree...
M src/mono/wasm/debugger/BrowserDebugProxy/MonoProxy.cs
Falling back to patching base and 3-way merge...
Auto-merging src/mono/wasm/debugger/BrowserDebugProxy/MonoProxy.cs
CONFLICT (content): Merge conflict in src/mono/wasm/debugger/BrowserDebugProxy/MonoProxy.cs
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 backport of 82852
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Error: The process '/usr/bin/git' failed with exit code 128Please backport manually! |
|
@thaystg an error occurred while backporting to release/6.0, please check the run log for details! Error: git am failed, most likely due to a merge conflict. |
|
@thaystg it's my understanding that the backport should only be done from main into the servicing branches, not from servicing to servicing:
Can you try that? Also, please send the email to Tactics if you haven't done so. The branch is now open. |
From main should not work in this case, but I opened it manually already. |
thaystg
added
Servicing-approved
ghost
locked as resolved and limited conversation to collaborators
Backport of #82852 to release/7.0
Customer Impact
It will not be possible to debug Blazor apps because newer Chrome/Edge versions started sending us instrumentation breakpoints pause and the Debugger.Paused message has the callFrames property with len = 0.
Then BrowserDebugProxy crashes and the customer cannot debug the app at all.
Testing
Manual testing
Risk
Low. We are just checking if the len of the callFrames property is 0 and returning false because we don't care about this kind of pause.
IMPORTANT: Is this backport for a servicing release? If so and this change touches code that ships in a NuGet package, please make certain that you have added any necessary package authoring and gotten it explicitly reviewed.