如何强制Chrome调试工具调试漂亮的代码？ [英] How to force Chrome debugging tools to debug in pretty code?

问题描述

虽然我使用漂亮的代码，并且在漂亮的代码选项卡中设置了断点，但是调试器在缩小的代码中保持工作。 （我看不清楚我在哪里，需要不断地在源代码和漂亮的代码之间切换）。
在同一个页面上，有相同的脚本，它有时候工作，有时不工作。我无法找到原因或者我激活它的方式有什么区别。

有没有办法强制调试器使用漂亮的代码？任何想法或其他问题？是否应该报告为错误？

编辑：我仍然不明白发生了什么，但有一个修复。所以当这种情况发生时，只需编辑脚本并添加debugger;光标后面的关键字它会做一个断点。那么，如果你使用漂亮的代码，调试器将保持内部的漂亮代码。正如我所说，我不明白为什么会这样发生，所以我还在等待答案。

编辑：当前浏览器版本是42.0.2311.135（ 64位）。

编辑：Dave指出，有一个非常类似的报告错误。 https://code.google.com/p/chromium/issues/detail?id=415406 它说它与文件大小相关，但我无法确认。我更改了标题来反映这些发现。

解决方案

你可以称之为错误。你可以称之为稀释。

从2013年8月9日开始的票证
（Chrome v。28）

Bug记者的观察

我一直在花费一些时间调试这个，并熟悉我的
如何在本地开发devtools;我不知道如果所有这些都是
有帮助，但这是一个大脑，我看到了迄今为​​止，一些
hunches：

当在原始.js文件中附加断点时，UI似乎
被困惑，并将断点分配给每个sourceMap关联的相关的.coffee或
.ts文件[参见image-1，但是，当取消选中要断开的断点时，UI将正确地
更新以在.js文件中的正确位置显示断点。
[见图2，附件]

在我看来，在
WebInspector.CompilerScriptMapping.rawLocationToUILocation或
WebInspector.CompilerScriptMapping.uiLocationToRawLocation

从2014年9月21日开始的机票
（Chrome v。37）

Chromium Developer's Observation

这不是很容易解决的问题。断点
的管理器围绕着这样的想法，即断点在最佳可能UI位置始终显示为
，这是源地图中
的未编译源。修复这一点将需要我们使用断点的
主要ui位置作为提示应该显示的位置。此外，
，因为执行行将在未编译源中以
默认显示，所以我们必须在
中显示我们的断点。所以这一切都需要同时在几个ui位置显示断点（和
执行行）。所有这些位置的
都可以顺利运行。

这是一个很大的努力，听起来不像我的GoodFirstBug
。

---

结论：

Prettify似乎没有创建一个新的非最小版本。而是渲染。这是有道理的。使用所有不同的框架和风格（例如Coffee），如果调试器创建了一个新文件，则存在高潜在的错误。

断点
管理器围绕着最好的断点总是显示
的想法， UI位置，这是未编译的源，例如
的源地图。

我将其解释为Chrome浏览器和调试器将从最新版本继续运行。当您在漂亮文件中设置断点时，调试器将其设置为最小化的文件，并为开发人员提供了一个漂亮的调试器渲染步骤，通过缩小的文件。

这是调试器管理很多，而且可能相当脆弱。我们可以称之为一个错误或非常雄心勃勃的功能，许多事情可能会出错。

**

我已将这个线程添加到这两个错误，并通过电子邮件发送给分配给它的开发人员。

**

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.

解决方案

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.

**

这篇关于如何强制Chrome调试工具调试漂亮的代码？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！