Although I used pretty code and had set up the breakpoints in \"Pretty code\" tab, debugger keeps working in minified code. (I can\'t see exactly where I am and need to continuo
Open ticket from Aug 9, 2013 (Chrome v. 28)
Bug Reporter's observations
I've been spending some time debugging this, and familiarizing myself with how to develop devtools locally; I'm not sure if all of this is helpful, but here's a braindump of what I've looked at so far and some hunches:
When attaching a breakpoint in the original .js file, the UI seems to get confused and assigns the breakpoint to the associated .coffee or .ts file per the sourceMap association [see image-1, attached]
However, when unchecking the breakpoint to disable, the UI correctly updates to show the breakpoint in the right place in the .js file. [see image-2, attached]
It seems to me there is either an incorrect lookup happening in WebInspector.CompilerScriptMapping.rawLocationToUILocation or WebInspector.CompilerScriptMapping.uiLocationToRawLocation
Open ticket from Sep 21, 2014 (Chrome v. 37)
Chromium Developer's Observation
This is not something that could be solved easily. The breakpoint manager is build around the idea that the breakpoint is always shown in the "best possible" UI location, which is uncompiled source in case of source maps. Fixing this would require us to use breakpoint's primary ui location as a hint to where it should be shown. Moreover since execution line will be shown in the uncompiled sources by default, it is essential that we keep showing our breakpoints in them as well. So this all ends up in the need to show breakpoints (and execution line) on several ui locations at the same time. All actions with these locations should work smoothly etc.
This is a significant effort and does not sound like a "GoodFirstBug" to me.
Prettify does not seem to create a new non-minified version. Rather it is rendered. This makes sense. With all the different frameworks and flavors (e.g. Coffee), if the debugger created a new file, there is high potential for error.
The breakpoint manager is build around the idea that the breakpoint is always shown in the "best possible" UI location, which is uncompiled source in case of source maps.
I interpret this to mean the Chrome browser and debugger will continue running from the minified version. When you set a break-point in a "pretty" file, the debugger sets it in the minified file and gives the developer a "pretty" rendering of debugger stepping through minified file.
This is a lot for the debugger to manage, and can be rather fragile. We can call this a bug or a very ambitious feature for which many things can go wrong.
**
**
Seems like you are clicking the "{ }" (pretty print) icon located in the bottom panel and setting a breakpoints there without attaching a source map of the original file.
When given a .map file, Chrome dev tools and map each line of executed minified code to the original source file using the data in the .map file. Otherwise it will just do it's best to indent/format the minified file.
I suggest you use grunt uglify or similar to minify your js which will automatically generate a map file for debugging. See the following links for more information on how to do this.
http://blog.teamtreehouse.com/introduction-source-maps
Javascript .map files - javascript source maps
In Chrome and Safari, simply select the 'Scripts' tab, find the relevant file and then press the "{ }" (pretty print) icon located in the bottom panel.
As of 2020, similar behavior still occurs in a specific situation:
The solution seems to be to go to the original source from which you mapped, prettify that, and place the breakpoint there.
Chrome 79.0.3945.88 ; Webpack 4.41.2
simply put debugger;
at top of the js code.
ex:
function add(n1, n2) {
debugger;
let sum = n1 + n2;
return sum;
}
How about this?: Generate the pretty-print version of your "min" version and save using your "min" version name: Substitute the "min" for a pretty "one"