There are a lot of reasons why breakpoints may not bind in the chrome debugger, and there are a bunch of tips for debugging this at https://github.com/Microsoft/vscode-chrome-debug. e.g. see the .scripts command to see which scripts are loaded and how the extension is resolving sourcemaps and mapping them to local files.

@roblourens However in this case it's the nodejs breakpoint that lose their sourceMaps, so the sourceMaps of the chrome extention are fine but the one directly is vscode are not.

Is there some debug switch to see vscode's sourceMap resolving ?

You said the backend configuration (node) works fine but the frontend (chrome)'s breakpoints are grayed out?

I've edited the comment to hopefully be more clear
The backend works fine, until I start a frontend , at this point the backend's breakpoint don't work anymore (sourceMaps failiure) but the frontend's work.

Oh, I understand. Thanks. @isidorn could there be an issue with a file that's shared between two debug sessions?

@roblourens not as far as I know, haved a shared file between two sessions should be no problem, since all breakpoints are sent to all sessions and vscode has no interpretation for source maps so each adapter handles them seperatly.
Let me know if there is a reproducable repository and I can look more, in the meantime my guess is that vscode frontend is not related to this issue.

@isidorn You can reproduce this with theia's repo here's how to do it:

git clone https://github.com/theia-ide/theia \
&& cd theia \
&& npm install \
&& cd config/local-dependency-manager \
&& npm install \
&& cd ../../examples/browser \
&& npm run bootstrap

• Open theia directory in VSCode
• Put a breakpoint in
  theia/src/terminal/node/terminal-backend-module.ts:38
• Start the Launch Backend configuration

You will then see the breakpoint is set properly.

Now in a shell:

do:

cd theia/examples/browser && npm run start:frontend

You will see your browser popup a page once the compile is done.

Now insdie vscode:

• Start the Launch Frontend configuration

You will see the breakpoint you had inserted before at
terminal-backend-module.ts:38 go grey and have a sourceMap problem.

But you can put a breakpoint in for example:
theia/src/terminal/browser/terminal-frontend-module.ts:42

Or any other place, that will work, but it will only trigger if that breakpoint is triggered by chrome, if you try to reset the breakpoint at theia/src/terminal/node/terminal-backend-module.ts:38 it will be set but it will never be hit.

To test if the breakpoints hit you can do "File -> New Terminal"

The terminal-backend breakpoint should hit in the nodejs process
and the terminal-frontend breakpoint should hit in chrome

This is easy to repro @isidorn, just grab any node app with sourcemaps, duplicate a launch config, and to the second one, add something like

            "sourceMapPathOverrides": {
                "*": "foo/*"
            },

That will just prevent breakpoints from binding.

• Launch the first launch config
• See BPs are red
• While it's still running, launch the second config
• See BPs turn gray
• They stay gray unless I reset them

Not sure how you should show BPs that are bound in one process, and unbound in another. Maybe show them red if they are bound anywhere, but show a hover with the warning from the debug adapter + the name of the launch config?

As you suggest: to simplify if one process says it is verified we show it as verified.
The hover and other fancy stuff we will add if the users get confused.

@hexa00 Please check in tomorrow's insiders if this fixes your issue

@isidorn my initial problem is that I wanted to have breakpoints active in both processes.

This will change the apperance but I'm still left with the need to open 2 vscode instances to debug two processes that share a breakpoint.

So from my point of view, this is not addressed and the issue should not have changed name...

Could we rename it back ? I'd rather avoid creating a new one.

@hexa00 I don't think there should be a problem with actually hitting the breakpoints in this case. If you aren't hitting breakpoints for the second launch config, it's probably due to it not being set up to resolve your sourcemaps correctly. Unless, it works when only running one launch config but not two at the same time.

If you post the output of the .scripts command on the launch config that doesn't work I'd be happy to help troubleshoot.

Unless, it works when only running one launch config but not two at the same time.

This is what is happening for me.

I'll send more info soon.

This is what is happening for me.

Oh, strange. Let's continue over in the debug adapter repo, I opened microsoft/vscode-chrome-debug-core#257 for you.

Steps for verifier, see above: #28817 (comment)

I tried to verify it using the steps provided by @roblourens but it is not clear to me if I succeeded. I did:

• simple TS app with a console.log("Hello World");
• compile with source maps
• create a launch config
• copy the launch config and add what Rob suggested
• start it and hit a breakpoint
• try to start the second launch config

What happening is nothing. The second program simple doesn't run. If this is what is expect now mark as verified. Otherwise please reopen.

What do you mean it doesn't run, does it not even start the second launch config? That shouldn't happen. It should run but not hit the breakpoint.

Just to recap (for the verifier):

Problem:
If two (or more) concurrent debug sessions return differing verification status for a (shared) breakpoint, then the outcome in the UI is not clear, e.g. we show the verification error for the breakpoint but he breakpoint actually verified fine in one of the sessions. This should not affect the ability to hit a verified breakpoint and miss an unverified breakpoint.

3 Possible solutions:

• The UI shows multiple breakpoint stati with a new UI: if a BP has different stati, we do not show the red dot but something else (and a hover could show the individual stati per debug session).
• Since VS Code has the concept of an active debug session, the UI could multiplex the different breakpoint stati: the UI reflects only the status of the active debug session.
• we use voting, e.g. we show the breakpoint verified if it got verified in at least one session. Any verification errors in other sessions are not shown.

Fix to be verified:
Solution 3.

@isidorn correct?

@weinand correct.

Though solution 2 sounds better since all our ux is sort of a slave to the active debug session. I can look into that in the future.

I've verified that the solution 3 works as described
(and I've created debt item #40158 to implement solution 2).