pwa-chrome launch and attach doesn't hit break points

[alexr00]

Testing microsoft/vscode#89393 on Windows

• Add the pwa- prefix to the Launch VS Code debug configuration in the vscode project.
• Set a breakpoint (You can do this before or after running the configuration)
• Run that launch config
  Expected: The break point resolves and is hit when the code path is run.
  Actual: I can't get any breakpoints to resolve so none are hit.

I tried commenting out the "Settings for js-debug" that are in that launch config, and it made no difference.

[alexr00]

Same issue with attach.

[chrmarti]

I can debug as usual when launching, but not when attaching to Chrome. (On Mac.)

When attached the breakpoints don't register (neither in TS nor in JS):

[connor4312]

@alexr00 can you enable trace: true and share your logs files?

@chrmarti in your screenshot, I don't see any sessions in the Call Stack view. This indicates that we couldn't find a target to attach to, most likely because we don't have a page matching the url pattern in your launch config. In my tour of heroes config I have "url": "http://localhost:4200/*",. Do you have something different in yours / did the config you have work for the existing debugger?

[chrmarti]

Putting the exact URL there ("http://localhost:3000/dashboard") shows the same behavior. Using something else shows an error dialog:

[alexr00]

renderer1.log

exthost.log

[connor4312]

Sorry, I should have specified more about what logs I was after!

When you enable trace: true, the debug console on the debugging process will print a file where logs are written. It'll look something like this--that's the file I'm after:

[alexr00]

vscode-debugadapter.txt

[connor4312]

@isidorn @weinand Alex and I debugged this over Live Share this morning (debugging over live share is super cool, by the way!) and it seemed like it might be some VS Code related thing.

Here's what happens. Like all sessions in js-debug, there's the top level "wrapper" sessions, and then debugees come in as children. The top level session works fine and it creates a session which is loopbacked to VS Code¹. The __pendingTargetId is what we use to reference the target we're holding onto to 'inject' into the new session.

I see this go through the Chrome config provider, which doesn't do much except for apply defaults that we actually don't really care about for delegate sessions. This is the config that gets returned. No errors get thrown as far as I can see. And then, nothing happens. The SessionManager (which is the registered debug descriptor factory) doesn't get a request, the attachment process just stops.

As with all the best bugs, I can't reproduce this on my Windows or OSX machines. Any ideas on what might be happening?

[isidorn]

So the gist is:
Breakpoints do not get sent to child session? Or none of the requests get sent to the child session?

@alexr00 Does it reproduce if you manually click on the child session in the callstack view?

[weinand]

@connor4312 if I interpret your last comment correctly you are saying that no child session is created?
If that is correct: are you calling vscode.debug.startDebugging() for a child session which does not result in a call to the createDebugAdapterDescriptor method of your debug descriptor factory?

[connor4312]

@weinand that's correct, the issue is that the child session is never actually created.

[weinand]

@connor4312 @isidorn so we only need to debug why "startDebugging" fails to call the factory.

@connor4312 have you tried that?

[connor4312]

If that is correct: are you calling vscode.debug.startDebugging() for a child session which does not result in a call to the createDebugAdapterDescriptor method of your debug descriptor factory?

Yes. I can verify:

1. startDebugging is called
2. we return a config (screenshotted above)
3. createDebugAdapterDescriptor on the sessionManager (registered for that debug type) is not called

[alexr00]

@isidorn there's nothing in the callstack to click on.

[weinand]

@alexr00 yes, there is no debug session at all, so the issue is completely unrelated to breakpoints.

[connor4312]

I'm seeing this happening very reliably in remote debugging (#337) iff I start the server before I start the debug session--which allows the page to load instantly (without the server, the remote debugging process launches chrome which then loads until the server starts). Seems like a race condition. Adding a bunch of console.logs (since debugging it changes timing and makes it work 😛 ):

1. The top level session's config is resolved. All normal.
2. We get a call to createDebugAdapterDescriptor as expected. Still all good. We create our debug adapter and then call the companion to launch the browser on the UI side.
3. We're now attached to the browser and see there's a new page we can attach to! We call vscode.debug.startDebugging with that __pendingTargetId that we want to attach to.
4. This loops back through the standard config resolution process.
5. And then nothing happens--the debug adapter descriptor factory doesn't get any calls.

If I wrap the startDebugging call in a one second setTimeout, it works quite reliably.

[isidorn]

@connor4312 we could do a meeting to look into this issue together. If you would like that feel free to book something in my calendar.

[isidorn]

Should be fixed via microsoft/vscode#91969
If this is not the case let me know and we can reopen the vscode issue and continue the discussion there.

Thanks all for providing details.

[alexr00]

Confirmed that this is fixed :)

[isidorn]

@alexr00 thanks a lot!