You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Show the debugger in DevTools when launching from VS Code #1792
I am running the following setup which is generally working fine:
[✓] Flutter (Channel stable, v1.12.13+hotfix.10-pre.1, on Mac OS X 10.15.4 19E266, locale en-DE)
[✓] Xcode - develop for iOS and macOS (Xcode 11.4)
[✓] VS Code (version 1.43.2)
Whenever I want to debug my app on the iOS simulator or device, I select Dart: Open DevTools in vscode.
But for some reason, the Debugger tab is deactivated in Chrome as you can tell from the screenshot:
Is there any way to enable debugging inside Chrome DevTools by default? Stripping away hide=debugger from the URL serves the purpose, but I prefer to avoid this doing manually.
Going through some old issues - @DanTup do we still add the hide=debugger query param when opening devtools from VS Code, and if so, do we still want to be doing this?
Yep, we still pass this if you open the non-embedded version.
Removing it makes it easy to have two debuggers connected which will cause issues with restarts (it's not clear who is re-sending breakpoints, or resuming after the restart).
There was talk of using DDS to improve this, but I don't know if that's done (or if so, whether DevTools and VS Code need updating to handle it) - I guess a question for @bkonyi?
Is there help for breakpoints too? To prevent VS code wiping DevTools breakpoints or vice-versa? And is DevTools updated to already use the API(s) above?
Nope, this basically just prevents another client from resuming underneath you while trying to reset breakpoints. The best way to handle this right now is probably to track which breakpoints your client has set and only reset them after a reload, leaving the other clients responsible for their own breakpoints.
Ah, got it. I'll look at adding this to the new SDK DAP (I don't think it makes sense to add to the old one we'll soon migrate away from). I think we'll need to ship it both there and in DevTools before we can safely enable the debugger tab (which might take a little while for VS Code, I suspect the switch over to SDK DAPs will probably start quite slowly - and there still a few small things to complete before that can start).
The VS Code debug adapters now use requirePermissionToResume and the upcoming version of the Dart-Code extension no longer explicitly hides the debugger when launching DevTools.
Activity
kenzieschmoll commentedon Feb 15, 2022
Going through some old issues - @DanTup do we still add the
hide=debuggerquery param when opening devtools from VS Code, and if so, do we still want to be doing this?[-]Debugging in DevTools[/-][+]Show the debugger in DevTools when launching from VS Code[/+]DanTup commentedon Feb 15, 2022
Yep, we still pass this if you open the non-embedded version.
Removing it makes it easy to have two debuggers connected which will cause issues with restarts (it's not clear who is re-sending breakpoints, or resuming after the restart).
There was talk of using DDS to improve this, but I don't know if that's done (or if so, whether DevTools and VS Code need updating to handle it) - I guess a question for @bkonyi?
bkonyi commentedon Feb 15, 2022
Are you talking about the client synchronization support that was added awhile back?
DanTup commentedon Feb 15, 2022
That certainly looks like some of it, yes! :D
Is there help for breakpoints too? To prevent VS code wiping DevTools breakpoints or vice-versa? And is DevTools updated to already use the API(s) above?
bkonyi commentedon Feb 15, 2022
Nope, this basically just prevents another client from resuming underneath you while trying to reset breakpoints. The best way to handle this right now is probably to track which breakpoints your client has set and only reset them after a reload, leaving the other clients responsible for their own breakpoints.
DanTup commentedon Feb 15, 2022
Ah, got it. I'll look at adding this to the new SDK DAP (I don't think it makes sense to add to the old one we'll soon migrate away from). I think we'll need to ship it both there and in DevTools before we can safely enable the debugger tab (which might take a little while for VS Code, I suspect the switch over to SDK DAPs will probably start quite slowly - and there still a few small things to complete before that can start).
jacob314 commentedon Apr 11, 2022
+1 to leveraging the https://github.com/dart-lang/sdk/blob/master/pkg/dds/dds_protocol.md#requirepermissiontoresume API. Only leveraging it in the DAP is fine. We'll need to also use the API in DevTools and verify that DevTools only reapplies its breakpoints and not al breakpoints.
DanTup commentedon Aug 27, 2024
The VS Code debug adapters now use
requirePermissionToResumeand the upcoming version of the Dart-Code extension no longer explicitly hides the debugger when launching DevTools.