Repository navigation
Make the "Select environment" prompt when launching a debugger clearer #146338
Description
If you press F5 in a project with no active file, you're prompted to select a debugger like this:
This dialog is quite confusing to Dart/Flutter developers, because when they want to run a Flutter app in Chrome, they must not select Chrome at the top, but rather Dart&Flutter. If they do select Chrome, it creates a launch.json that has "type": "pwa-chrome" which means they are not prompted at all the next time they press F5, the launch just doesn't do what they'd expect. They need to know to manually go and delete the launch.json to resolve the issue.
This has come up a few times:
- Web - VSCode launches on localhost:8080 by default, refused to connect Dart-Code/Dart-Code#2911 (comment)
- Web - VSCode launches on localhost:8080 by default, refused to connect Dart-Code/Dart-Code#2911 (comment)
I think there are some tweaks that would make this clearer and avoid the confusion:
- Don't call this "environment", since that's easily confused with the environment in which you want to run the app. Saying "Select debugger" would be clearer
- Use some heuristics to sort the entries.. If the Dart/Flutter extensions are activated it's almost certain that Chrome is the wrong option
- Don't create a launch.json by default for
pwa-chrome. There are entries on the Debug side bar for creatinglaunch.json, one with default values is pointless and makes it harder to recover from a mistake like this
Activity
roblourens commentedon Apr 5, 2022
DanTup commentedon Apr 5, 2022
Perhaps this could be influenced by languages? VS code already knows to use the Dart debugger if the active file is Dart, so perhaps it could infer that if a project is 90% Dart (or 90% Python) that it could "suggest" the Dart/Python/whatever extension at the top as a "Suggested debugger"?
I mean selecting the Chrome entry should not create a
launch.jsonunnecessarily. It can be created by the user from the debug side bar if they need to customise it. A lot of debuggers just run without the file altogether now (like Dart). The issue with creating it here is that it forces every subsequent Run/Debug to go through that path, so if the user accidentally picks Chrome (as has happened to at least a few Dart users), it changes future behaviour to do the wrong thing unless they understand exactly what happened here (which is, their bad selection wrote a file that causes that same selection to be made automatically next time).weinand commentedon Apr 5, 2022
Danny Tuppeny (@DanTup) I like your suggestion to make it "harder" for a user to create the "wrong" launch.json (or to create a launch.json at all, given that more and more debuggers try to avoid the need for launch.json anyway).
... and I agree that we could use the "debuggers.languages" contribution to determine the "debugger nature" of a workspace folder:
Today this information is used to map the active editor contents to a specific debugger (if a user has pressed F5 and no launch.json exists). But we could use the same information to determine the "language" frequency distribution for the files in a workspace and assume that this results in a ranking for the available debuggers.
If this ranking shows a clear winner, we could actually avoid the "Select environment" QuickPick completely and use the same code path that we use for F5 in an active editor (the only difference for the underlying debugger extension would be the missing document URL in this case...)
But even if we do not want to avoid the "Select environment" QuickPick, we could change its behavior like this:
Danny Tuppeny (@DanTup) roblourens Connor Peet (@connor4312) what do you think?
DanTup commentedon Apr 5, 2022
Both sound good to me. Avoiding the prompt altogether if it can be reliable prevents the user from picking the wrong thing at all. If that's not possible (or not in all cases), then not creating
launch.jsons just from this selection at least prevents the bad choice being made automatically next time.weinand commentedon Apr 6, 2022
Isidor Nikolic (@isidorn) what do you think about my proposal from above?
isidorn commentedon Apr 6, 2022
Andre Weinand (@weinand) I like the push towards reducing the wrong automatic creation of
launch.json. Since having a wronglaunch.jsoncan put the user in a very hard spot. Also it will be more consistent with the other flow. Auto creation of launch.json was the first step we did before dynamic providing of launch configurations, and now this feels like debt behaviour to me.While I like your idea to count files and rank debuggers, I am not sure if that would help here. Since both Chrome and Dart are probably interested in same files, so they would most likely be ranked the same. Thus you would still have to ask the user. Or am I missing something?
DanTup commentedon Apr 6, 2022
This probably isn't the case. Flutter projects will likely only have one (or a very small number) of
.htmlfiles (and probably no.js), and be mostly.dartfiles.If there are more
.html/.jsfiles in a workspace than.dart, then ranking the Chrome debugger above wouldn't be unreasonable to me (although, whether it should be automatically picked rather than just "suggested" at the top of the list, I'm less certain).That said - it's possible after running the Flutter: New Project command you'll end up with exactly one
.dartfile, and exactly one.htmlfile from the default template, so in some cases at least, it might not be a clear winner. For most non-skeleton projects, it's likely there will be more.dartfiles added (and no additional.htmlfiles) though.weinand commentedon Apr 6, 2022
Isidor Nikolic (@isidorn) in order to verify that my proposal actually works, I did an experiment:
So you are right: Chrome debug would win with 2:1!
But I think that could be fixed if Dart would more aggressively capture more web related types. If Dart would just add "html" and "css", it would win with "3:1" ;-)
In addition, the second part of my proposal would address this problem:
We would show the "Select Debugger" Quickpick because there is no clear winner.
If users know what they are doing, they would probably pick the Dart debugger if they want to develop a Dart web app.
But then we would no longer create a launch.json but instead transfer directly into the Dart debugger's "resolveDebugConfiguration" hook which can handle the case.
DanTup commentedon Apr 6, 2022
btw, the reason users are used to selecting Chrome in a picklist like this, is for Flutter we let you change the target device and since there aren't many UI options in VS Code, it's done via a picker like this:
FWIW, Dart web apps that don't use Flutter are not so common compared to those using Flutter. The Flutter: New Project command is a more interesting case to me which looks like this:
Because of the default test created, there are actually two
.dartfiles, not one. If #74671 was implemented, things could be a bit more specific because Dart could listpubspec.yamltoo, which is very Dart-specific (as isanalysis_options.yaml).elahehrashedi commentedon Apr 11, 2022
As the issue #146956 is closed, allow me to mention our request in this thread:
In C/C++ extension we have two debuggers that we can't combine them into one debugger.
When there are few debuggers from other extensions, it makes sense to ask for "Select environment" or "select debugger", but is it possible not to select the environment/debugger when the debuggers are from the same extension?
in other words, Is it possible to skip the step of selecting the debugger type and instead provide a list of configurations across all debugger types in the extension? c.c. Julia Reid (@jureid)
29 remaining items
More explicit DA names (#1271)
Localize "Suggested"
DanTup commentedon May 17, 2022
Yeah, I've been caught out by those dynamic entries appearing in the Debug side bar dropdown too. I spent some time trying to find a
launch.jsonthat has an unexpected named debug session before I realised where it had come from. It would be nice if the view was more consistent before/after running the first session, and it was clearer in that drop-down what the source of the configurations were.More explicit DA names (#1271)
Localize "Suggested" (#149684)
Sort used debug extensions to the top when clicking "Run and Debug". …
Sort used debug extensions to the top when clicking "Run and Debug". …
Localize "Suggested" (microsoft#149684)
Sort used debug extensions to the top when clicking "Run and Debug". …
isidorn commentedon May 19, 2022
roblourens these are cool improvements 👏
For the history behind those decisions feel free to schedule a sync with me. I will be happy to try to help :)
Sort already-activated debug extensions to the top when clicking "Run…
roblourens commentedon May 30, 2022
Closing this for this month's improvements - can continue in #150663