search

microsoft / vscode-chrome-debug-core

A library for implementing VS Code debug adapters for targets that implement the Chrome Debugging Protocol.
Other
157 stars 119 forks source link

Breakpoints in eval scripts aren't rebound after refreshing the page #45

Open roblourens opened 8 years ago

roblourens commented 8 years ago

Microsoft/vscode-chrome-debug#158 brought in sourcemap support for eval scripts. However, rebinding breakpoints on refresh depends on the Chrome API Debugger.setBreakpointByURL, and eval scripts don't use that since they don't have URLs. I need to keep a mapping of sourcemap URL to breakpoints in eval scripts, and restore these manually after the page refresh. I think this is what Chrome devtools are doing. That doesn't work naturally with the general design so I need to think about how to do that.

There is a hash parameter with the scriptParsed event, but it works in CDT even when the script changes, so I don't think they're using it for this.

Also this won't work for breakpoints in global code, but that's impossible for eval scripts, and CDT doesn't do that either.

auchenberg commented 8 years ago

Doesn't inline scripts have a sourceUrl set? That's how they are treated in Chrome. On of their tests, https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/inspector/sources/debugger/dynamic-script-tag.html?q=scriptParsed&sq=package:chromium&l=73&dr=C

roblourens commented 8 years ago

These aren't inline scripts or dynamic scripts, there is one .js file that has

eval("script 1 js... // inline sourcemap")
eval("script 2 js...// inline sourcemap")

And each eval produces a scriptParsed with an id and the sourcemap info. We don't even get the parent doc id (Edge FTW).

roblourens commented 8 years ago

I consider this low-priority because if you encounter this, you're probably using webpack or some other bundler, and the workaround is... use a different sourcemap output mode, or reset your breakpoints after refreshing.

auchenberg commented 8 years ago

Aha, indeed low priority.

nelsonlaquet commented 8 years ago

It would be great if this were fixed. Having to use source-map instead of eval (even the cheap-module variety) significantly impacts performance, since the entire sourcemap has to be re-generated on every build. The "eval" varieties only have to update the sourcemap of the changed module.

This can be somewhat mitigated by code-splitting vendor libraries, which should be done anyway, but as your application grows your recompile times are going to increase massively.

Without this, I can't debug any startup code, which is frustrating.

roblourens commented 8 years ago

Thanks for the explanation. Not sure I understand why these frameworks bundle all the js to one file, though. Wouldn't be times be faster when it only has to write the files that changed, instead of regenerating the entire bundle.js or whatever on each change?

The 'debugger' statement should still work as a workaround, though.

FredyFadel commented 6 years ago

Not so low priority. For divers reasons we eval our javascript code (which contains a commented # sourceURL=name.js). In FireFox and Chrome breakpoints are conserved between debug sessions but in edge and IE11 they are lost. Placing a debugger; in the code works but is very time consuming. Is there a workaround ?