How to force Chrome debugging tools to debug in pretty code?

21,851

Solution 1

You can call this a bug. You can call it a dillema.

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.


Conclusion:

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.

**

I have added this thread to both bugs and emailed both developers assigned to it.

**

Solution 2

Icons help

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.

Solution 3

As of 2020, similar behavior still occurs in a specific situation:

  • You open a source-mapped document, i.e. it shows "(source mapped from ...)" on the bottom of the window
  • You prettify it
  • You place a breakpoint in the prettified version
  • The debugger will stop in the ugly source-mapped file

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

Solution 4

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

Solution 5

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"

Share:
21,851
Ante
Author by

Ante

Updated on July 09, 2022

Comments

  • Ante
    Ante almost 2 years

    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 continuously switch between source and "pretty code"). On same pages with same script it sometimes work and sometimes don't. I can't find the cause or any difference in the way I activate it.

    Is there any way to force debugger to use "pretty code"? Any Ideas or additional questions? Should this be reported as a bug?

    EDIT: I still don't understand what is going on but there is a fix for it. So when this situation happens, just edit script and add "debugger;" keyword after the cursor. It will make a breakpoint. Then, if you use "pretty code", debugger will stay inside prettified code. As I said, I don't understand why is this happening so I'm still waiting for answer(s).

    EDIT: Current browser version is 42.0.2311.135 (64-bit).

    EDIT: Dave pointed out that there is a reported bug on something very similar. https://code.google.com/p/chromium/issues/detail?id=415406 It says it's related to file size but I can't confirm this. I changed title to reflect these findings.

  • Ante
    Ante about 9 years
    As I said, I'm using {} and it works fine. But, in some cases debugger only works in minified source. If I switch to 'pretty code' on 'step over' it will change tab, open minified version again and make step over.
  • Ante
    Ante about 9 years
    Thanks for the answer. I'm aware of source maps and how they should be used but I'm asking about the behaviour of debugging tool when source map is not available. Let's say I'm trying to debug some third party script.
  • Kutyel
    Kutyel about 9 years
    @Ante if you are debugging a third party script and you are referencing a minified script, you will always see it minified. This happened to me the first time I was trying to debug angularjs. It was solved adding the script reference to a non-minified version. :)
  • user441521
    user441521 almost 7 years
    I know you got down voted for this but having this picture is amazing! Thank you.
  • oriadam
    oriadam almost 7 years
    I am debugging my own minified script on to track a bug on production. I wouldn't want to publish the map file on the production site. Is there a way to keep mapping and source files on a different location?
  • Steve Brooker
    Steve Brooker over 6 years
    Like others Chrome Dev Tools seems inconsistent and refuses currently to pretty print my minified code so I cannot set debug lines. Your idea helped me by thinking sideways so I just set my minifier to keep the line breaks and re-ran the debug session. Thanks
  • Dave Alperovich
    Dave Alperovich over 5 years
    I think you missed the point of the post. OP asked about breakpoints and code steps not always following what is display by "prettyfied" styles
  • Junlong Wang
    Junlong Wang over 2 years
    This is what I did but not working