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

筅森魡賤 提交于 2019-12-02 20:11:15

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.

**

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.

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"

Chris Gunawardena

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

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!