debug: allow debugging the renderer process #100242
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This adds a new parameter to the `launchVSCode` request -- `debugRenderer`. If set to true and we're in Electron, the main process will attempt to stand up a CDP-speaking server and respond with the port the debugger can connect to in order to handle debug events. Note: this only works when webviews are iframe-based. It's _possible_ to do the same treatment to webviews with greater complexity. I didn't implement that today, and maybe we say since iframes are coming eventually (and they can be toggled on with a user setting that we could have in the starter...) we don't need do add handling for that. This does not work when debugging in web because there's no way to force the browser to enter debug mode. Code in this PR is still rough, I will keep this in PR until I have js-debug working end to end and iron out any kinks.
weinand
added
the
debug
connor4312
force-pushed
the
connor4312/expose-webview-cdp
branch
from
6ce01c3
to
1513428
Compare
|
@weinand this is ready for review now; I've got the scenario working end to end now, pending polish on the js-debug side of things. |
connor4312
added a commit
to microsoft/vscode-js-debug
that referenced
this pull request
Jun 24, 2020
- soft dependency on microsoft/vscode#100242 - fixes microsoft/vscode#100242 With these changes, you can now add `debugWebviews: true` (or a Chrome configuration object) to an extension host configuration to attach and debug webviews. It works.  Todo: - As mentioned, this only works with iframe-based webviews. This is where VS Code is moving towards and Electron webviews are a different beast that I don't think it's worth dealing with. - Currently, it attaches to all webviews in Code instances - The name of the webview debug sessions is a long URL This can be most easily fixed by exposing some data in the webview title, cc @mjbvz. Alternatively, we could have some messaging in a custom message that the main process can send over to js-debug to tell it about webviews.
weinand
reviewed
Jun 25, 2020
|
I updated the IExtensionHostDebugService and I think will need to make the corresponding change in the server. I'll do so and merge. |
The `purpose` can be used for notebooks instead of the extension ID, since there's no extension associated with the renderer view. The renderer URL now looks like: ``` https://<guid>.vscode-webview-test.com/<random>/index.html?id=<guid>&extensionId=&purpose=notebookRenderer ``` And a renderer is: ``` https://<guid>.vscode-webview-test.com/<random>/index.html?id=<guid>&extensionId=connor4312.vsix-viewer&purpose=undefined ``` I wanted to put this in the page title, but unfortunately this is hard due to https://bugs.chromium.org/p/chromium/issues/detail?id=1058108. Instead, add it to the url which _is_ available and given in the first targetInfoChanged event.
|
yarn web and web debugging actually do work for me with these changes (webviews can't be debugging in web because browsers, but that's expected). I thought I had to change something in the server but it looks like that's not the case. The error you're running into looks unrelated most likely. |
mjbvz
approved these changes
Jun 25, 2020
connor4312
added a commit
to microsoft/vscode-js-debug
that referenced
this pull request
Jun 26, 2020
* fix: increase repl character budget significantly Fixes microsoft/vscode#100786 * feat: implement webview debugging - soft dependency on microsoft/vscode#100242 - fixes microsoft/vscode#100242 With these changes, you can now add `debugWebviews: true` (or a Chrome configuration object) to an extension host configuration to attach and debug webviews. It works.  Todo: - As mentioned, this only works with iframe-based webviews. This is where VS Code is moving towards and Electron webviews are a different beast that I don't think it's worth dealing with. - Currently, it attaches to all webviews in Code instances - The name of the webview debug sessions is a long URL This can be most easily fixed by exposing some data in the webview title, cc @mjbvz. Alternatively, we could have some messaging in a custom message that the main process can send over to js-debug to tell it about webviews. * fix: tests * feat: name webviews better, support url filtering
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds a new parameter to the
launchVSCoderequest --debugRenderer. If set to true and we're in Electron, the main processwill attempt to stand up a CDP-speaking server and respond with the port
the debugger can connect to in order to handle debug events.
Note: this only works when webviews are iframe-based. It's possible
to do the same treatment to Electron webviews with greater complexity. I didn't
implement that today, and maybe we say since iframes are coming
eventually (and they can be toggled on with a user setting that we could
have in the starter...) we don't need do add handling for that.
This does not work when debugging in web because there's no way to
force the browser to enter debug mode.
Code in this PR is still rough, I will keep this in PR until
I have js-debug working end to end and iron out any kinks.
Works towards #96626