F10 and F11 should start debugging with stopAtEntry:true

[Spongman]

in visual studio (not vscode) you can start debugging and stop at the first line of code by pressing the step over or step into keys. this is distinct from hitting the start debugging key which doesn't stop at main (or wherever). it's incredibly useful to easily choose whether or not to stop at the first line of code, especially for console apps.

can we get similar functionality added to vscode? it's a pain to have to switch debug configurations, or edit the stopAtEntry setting just to do this.

[pgklada]

I support the request: enable starting a debugging session with F10, that positions the "instruction cursor" at the first instruction of the script

[pgklada]

@isidorn, do I get this right? you removed this from the backlog?

[isidorn]

I like this idea and we plan to add this soon thus I am assigning this to On-Deck
fyi @weinand

[weinand]

@isidorn "stopAtEntry" is a private attribute of some debug extensions. It will be difficult to support that generically (if we want to avoid ugly heuristics).
Alternatively we'll have to find a way (based on extension API) so that debug extensions that support "stopAtEntry" can register actions in their extension.

[isidorn]

@weinand good point, I forgot that "stopAtEntry" is not generic.
Well I think this can already be done, here's how:

• A debug extension registers a new command and has a keybinding for it when not in debug mode
• The command simply calls start debugging and patches the stopAtEntry in the resolveConfiguration call

Am I missing something?

[weinand]

Sounds good. A prototype would be a good proof of concept.

[isidorn]

I have introduce a new context key in vscode
debugConfigurationType which has the vlaue of the selected configuration type.
Only when that type is node the node extension now contributes Start Debugging and Stop on Entry commands which can be run via F10 and F11.

fyi @roblourens

[roblourens]

I'm a little worried about this global variable in the config provider: microsoft/vscode-node-debug@0f004a2#diff-35cf5c034aecdc798ffe64808bf07609R18

You could have debugging fail to start on vscode's end for some reason so the next call to resolveDebugConfiguration is not actually associated with that workbench.action.debug.start, or a race between multiple session starts, or something else that could cause confusing issues...

Is there any way to get rid of that? Like if we could pass some override config props to executeCommand? Or props that get passed through to resolveDebugConfiguration?

[isidorn]

@roblourens anything that passes through vscode does not really make sense since vscode is unaware of stopOnEntry attribute.
Though I agree with your concerns, but the worst case is that something will stopOnEntry when it should not in a weird corner case. I personally do not see this as a big issue.

[connor4312]

It looks like the current Action implementation doesn't support taking arguments, to fix this we should convert off the deprecated registerWorkbenchAction to registerAction2, which takes an Action2. I don't want to do this a couple hours before the end of the iteration, so pushing it to next milestone.

[alexr00]

These are just not working for me. I have the latest JS Debug nightly extension. F10 doesn't appear to do anything. F11 toggles full screen. My keyboard shortcuts look correct:

Is there something I'm missing?

[connor4312]

@alexr00 Make sure you have a Node.js configuration currently selected in the "run and debug" menu

[connor4312]

I realized I forgot to bump the builtin version of the old node-debug when I changed the setting, which is why you see a duplicate keybinding there. For me it still works, but that might cause issues c881465

[alexr00]

Ah forgot to include by debug config:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "type": "node",
            "request": "launch",
            "name": "Launch Program",
            "program": "${workspaceFolder}/server.js"
        }
    ]

That config is selected in the debug viewlet.

[connor4312]

Hm, okay. This works for me on both OSX and Windows. If this doesn't work in tomorrow's Insiders for you, please let me know and we can debug together when you have time

[connor4312]

Steps:

1. Create a Node.js launch config, and select it in the debug view
2. Hit F10
3. The program should run and pause on the first line of the script

[connor4312]

Tyler tried to verify and hit the same issue. The selectedConfiguration in the debug service was missing its getConfig method. It looks like selectConfiguration can actually be called with undefined which 'resets' the selected config, even when there's still a selected configuration shown in the dropdown. This easiest way to trigger this is to make a change to your launch.json, then the command will break.

I think my previous fix was not really correct -- newer, better, one coming.

[TylerLeonhardt]

Works great!