Change:
Steps to Reproduce: , Chrome (JS template) breakpoint into the hello world command handler "hello world" = breakpoint not hit
This seems to be an issue with . Turning the new JS debugger off with the setting makes it work for me. if a fix for this is more involved, I suggest to force js-debug being disabled for this scenario.
I think this may be something in core. This is what js-debug does: Get the launch request, process it like normal. Fires the custom launchVSCode DAP request. These are the arguments, they're essentially the same as node2, except it passes instead of since it does not depend on the entrypoint breakpoint.The launch request sends it termination as normal. At this point, VS Code should hand us an "attach" request. However, this does not happen; neither the DebugConfigurationProvider nor the DebugAdapterDescriptorFactory are called. As a result we do not attach. I will look around today in VS Code to see if I can see anything going obviously wrong, +isidorn
Indeed, I think that is the root cause; changing the argument to inspect-brk makes it work (albeit with an incorrect break at the start). It seems that here, we look at inspect-brk, but not inspect-. ~For some reason I can't debug either js-debug or node2 extension hosts running web locally so I can't validate the fix, I would appreciate it if someone could give the linked PR a shot.~ I managed to get it running and validated it. Would still appreciate eyes to make sure I didn't miss anything
Running out of sources at least I still cannot hit a breakpoint. Is there any setting I need to do?
Can you enable in the launch config and share the logs here?
Probably doing something wrong here, but I cant seem to get extensions to work on the web. I built from distro and I was able to run the extension, but in the target window the contributed command isn't available.
I was able to test by running this in distro (had to manually apply my changes locally there) (Running that command in oss failed with ) The "Selfhost Setup" worked in both places as well -- since this is now in Insiders that should work for you as well and be the easiest way to test this.
Does it help if you run "yarn gulp mixin-server" in OSS before starting the webui with the command 6. from above?
worked from oss, thanks !
Ah, yep, looks like web is in a happier state today. I had 'd and re-mixin'd a few times last night with no luck, there must have been some synchronization issue between oss and distro..
While I am getting this to work with a TS extension, it does not work for me with a JS extension. I generated a simple hello world extension with JS and tried to debug.
I'm unable to reproduce this with a fresh JS sample  It's possible that you were hitting We of course don't need sourcemaps for plain .js files but that might be interfering with some logic. Please enable in your launch config -- that will let me confirm or have enough information to debug either way.
a pre-req for this seems to be that I first had another folder opened and then switched to it. Steps: within web open the folder with the JS extension to debug start debugging =no breakpoint hit for me
Unfortunately I'm not able to repro with those steps on my machine Can you enable in your launch config and share the logs?
so it seems to be timing related, if I invoke the action early enough the breakpoint is not hit, but if I wait a bit it seems fine. Logs for an unsuccessful attempt:
Okay. I also saw that in one run where I invoked it very early and missed a breakpoint. I think the attachment to the extension host is given async, perhaps just in web or maybe web is slightly slower for some reason since we don't hit this on desktop. From the logs I see that js-debug finished setting up and verified your breakpoints in 2.1 seconds after it got the "attach" request, so it does not seem to be js-debug that is unduly slow, though that may be slightly slower than the previous node debugger. I think the best solution would be to call  in the extension host so that nothing happens until attachment happens. thoughts?
I can reliably reproduce this problem both with TS and JS extensions by enabling early extension activation with the wildcard activation event ("*"). With this I never hit a breakpoint in the activation method with js-debug, but I always hit it with node-debug2. Since this problem only occurs in the Web, I think we can swallow it in this milestone. But we need to fix it in June. (Using "inspector.waitForDebugger()" might be one solution to solve the problem, but I do not want to add this new code today).
I fixed this in the linked commit (see details) Waiting for the tab's title to change indicating a breakpoint hit is still very slow in web when the tab isn't focused (like a 5-10 second delay) but it works consistently.

Discussion:
environment.set('inspect-brk-extensions', inspectBrkExtensions); } <ins> const inspectExtensions = this.findArgument('inspect-extensions', args); if (inspectExtensions) { environment.set('inspect-extensions', inspectExtensions); } </ins> // Open debug window as new window. Pass ParsedArgs over. return this.workspaceProvider.open(debugWorkspace, { reuse: false, 								// debugging always requires a new window

extensionHostDebugEnvironment.params.port = parseInt(value); extensionHostDebugEnvironment.params.break = true; break; <ins> case 'inspect-extensions': extensionHostDebugEnvironment.params.port = parseInt(value); break; </ins> case 'enableProposedApi': extensionHostDebugEnvironment.extensionEnabledProposedApi = []; break;