Bug 40969 – Web Inspector: Prettyprint the contents of the scripts tab in case it is minified.

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Web Inspector (Deprecated)

[Pavel Feldman]

I think we should start with no heuristics, toggling pretty print using status bar button or context menu.
We probably should start with the naive approach of pretty-printing on the front-end side + storing line / column mapping for breakpoints.

For breakpoints to work, this would require setting them by line:column or offset. There is such a capability in V8, but it is not there (at least not exposed yet) in JSC. Timothy, Joe, how hard is it for you to add that?

[Joseph Pecoraro]

(In reply to comment #0)
> For breakpoints to work, this would require setting them by line:column or offset.
> There is such a capability in V8, but it is not there (at least not exposed yet) in JSC.
> Timothy, Joe, how hard is it for you to add that?

Good question. To date I have only scratched the surface of JavaScriptCore.
So I took a look at this. It looks to me like JSC emits a possible debugger
breakpoint message after each statement. And the location data provided
for that statement (firstLine() and lastLine()) are originally set in the grammar
via a call to setLoc(). So it would involve a change would need to be made to
JavaScriptCore's grammar / parser.

Incidentally there is already work underway for improvements to the parser:
https://bugs.webkit.org/show_bug.cgi?id=34019

@Oliver Hunt and Zoltan Herczeg, how difficult do you think this would be
to add to your new JavaScript parsers or even the existing parser? I would
appreciate your expert opinions!

[Joseph Pecoraro]

(In reply to comment #0)
> I think we should start with no heuristics, toggling pretty
> print using status bar button or context menu.

Also, what did you mean by no heuristics?

[Zoltan Herczeg]

As for nodes in the Abstract Syntax Tree, there is an m_line (int) member for each nodes, but only StatementNodes where its value is trusted (moreover, m_lastLine is right for StatementNodes as well). It is the nature of the bison parser that it could not capture all line locations, since it usually reads some tokens ahead before it could make a decision (thus, the callback handlers do some guesswork to get some useful data). Those nodes, which inherites from ThrowableExpressionData, a "start" and an "end" offset are also provided.

Basically, after the byte-code is generated, the AST is dropped, and the byte-code does not contain line info except for op_debug instructions. However, if an exception occurs, the code is reparsed again, and the line info for all nodes are stored in the CodeBlock (see CodeBlock->lineNumberForBytecodeOffset())

The recursive descent parsers would be capable to do this for all nodes without line info error.

[Timothy Hatcher]

*** This bug has been marked as a duplicate of bug 14469 ***