43

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
  • 8,567
  • 17
  • 58
  • 70
  • 3
    I would assume you're using version 41, but I ask because this was a known issue in 39, seemingly solved in V 40. – Dave Alperovich May 11 '15 at 16:15
  • Do you have any link to this bug so I can check it out? – Ante May 13 '15 at 07:38
  • 1
    This isn't the one I was referring to, but https://code.google.com/p/chromium/issues/detail?id=415406 – Dave Alperovich May 13 '15 at 14:15
  • Thank you, this problem seems identical. As I can see there, it isn't fixed? It's a bit old, appeared in v37. – Ante May 14 '15 at 16:42
  • It actually was fixed. Several releases ago. You may have discovered a regression bug (happens all the time). I'm trying to reproduce your bug, and if so, log it for 42. Can you give any advice to help. – Dave Alperovich May 14 '15 at 16:53
  • I would suggest a complete uninstall and re-install. If problem persists, try going back to 41 and try again. I'd like to see if we can baseline a version that doesn't have that problem. If not, the problem may be on your machine (certain kinds of registry corruptions can impact chrome debugger). It's delicate in how tightly it configures. – Dave Alperovich May 14 '15 at 16:55
  • I'm using v.41 and so far cannot reproduce issue – Dave Alperovich May 14 '15 at 17:30
  • 2
    I lodged the Chromium bug being referred to. It is very inconsistent as to when the issue occurs. The same script file used on different sites will not necessarily manifest the problem. The issue certainly still exists: I have hit it again today on Chrome 43 (OS X) – SimeonJM Jun 11 '15 at 04:13
  • followup on this issue. This bug, originally believed fixed, has been identified on many platforms and latest versions. https://bugs.chromium.org/p/chromium/issues/detail?id=415406 – Dave Alperovich Mar 27 '16 at 03:05
  • One year later, still no fix for this. – Ante Oct 28 '16 at 13:28

7 Answers7

14

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.

peterpeterson
  • 1,315
  • 2
  • 14
  • 38
  • 14
    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 May 11 '15 at 09:59
  • 2
    I know you got down voted for this but having this picture is amazing! Thank you. – user441521 Jun 22 '17 at 18:26
  • 2
    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 – Dave Alperovich Oct 11 '18 at 20:25
12

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.

**

Dave Alperovich
  • 32,320
  • 8
  • 79
  • 101
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

Andrew Olney
  • 691
  • 4
  • 12
1

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

Community
  • 1
  • 1
Chris Gunawardena
  • 6,246
  • 1
  • 29
  • 45
  • 3
    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. – Ante May 13 '15 at 07:34
  • @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. :) – Kutyel May 18 '15 at 08:52
  • 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? – oriadam Jul 01 '17 at 10:32
1

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"

Pakosis
  • 19
  • 5
  • 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 – Steve Brooker Oct 27 '17 at 13:22
0

simply put debugger; at top of the js code.

ex:

function add(n1, n2) {
  debugger;
  let sum = n1 + n2;
  return sum;
}
Mahesh Muttinti
  • 17
  • 4
0

To debug a third-party npm library during local development.

  1. Update package.json from "node_modules[package_name]\package.json"

    "main": "dist/package-minified.js" -> "main": "dist/package-formatted.js"

  2. Rebuild your project

You will be able to set a breakpoint to the third-party js library.

Usually, libraries come with both formatted and minified js files. You will find them under node_modules[package_name]

  • dist/[package-name]-src.js
  • dist/[package-name]-min.js
Vaisakh Rajagopal
  • 1,189
  • 1
  • 14
  • 23