Chrome Dev Tools Scope
See original GitHub issueHello,
Firstly, thank you for this amazing tool. CodeSwing is a part of my daily development workflow. I use it all the time — especially when building-up Tailwind components and fiddling with all of those utility classes.
At one point in time, it seemed like the Chrome DevTools integration was working really well, but it now seems that when I use them, the DevTools scope is set to top
— giving me VSCode’s Electron context instead of the CodeSwing preview window. If I adjust this, it retains for a moment, but then jumps back to the top
context as soon as I save my swing to render the next preview.
Is there something I’m missing or perhaps a setting I need to adjust? As this is a tool I use daily, I’m more than happy to troubleshoot and open a pull request, but before I start investigating, I figured I should first see if there’s an easy fix.
Thanks!
Issue Analytics
- State:
- Created 2 years ago
- Comments:9 (1 by maintainers)
Top GitHub Comments
@egamma, after installing the extension, run the
CodeSwing: New Swing...
activity from the command palette:Then, choose one of the pre-defined templates. Here, I’m using the
HTML/CSS/JS
template:Next, use either the toolbar shortcut or the command palette to show developer tools, and use the context selector to choose the CodeSwing document/iframe component:
That last step is where the trouble begins. Traditionally, the inspector would immediately focus on the CodeSwing doc, and remain focused. However, as the CodeSwing doc is saved/updated, focus is lost, and the context of the console/devtools returns to the
top
scope.Indeed, if we add some
console.log()
statements toscript.js
, and save/execute (with the preserve log option enabled), we can observe that the log messages originate from a different context each time.We changed the behavior of
Developer: Open webview developer tools
when we moved to use standard iframes to host the webview. The command is intended to be used by developers who are building webview extension and we believe that using a single unified developer tools makes sense for that use case: https://github.com/microsoft/vscode/issues/129437#issuecomment-897889739It doesn’t seem like we can easily go back to the old behavior. I think connecting the edge dev tools sounds like a better approach for this use case, as presumably you could also then hide all the webview implementation details from users so that they just see their code