424104 - Enabling pretty print produces an error message

Status: RESOLVED INCOMPLETE

(Other Applications Graveyard :: Venkman JS Debugger, enhancement)

Description

[David Mårtensson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4
Build Identifier: 0.9.87.2

When trying to debug a site with large compacted JS files it is impossible to set valid breakpoints as they are set by line of source code.

This could be helped if pretty prin worked but this seams not to work, I got an error message when trying.

Reproducible: Always

Steps to Reproduce:
1. Open the url given.
2. Open any of the ComponentArtScript.axd files
3. Try to set a breakpoint inside any of the functions embedded in the lines in the file.
Actual Results:  
The breakpoint is set for the whole line.

Expected Results:  
I would like to be able to set the breakpoint on a specific statement OR to be able to reformat the source to a format where conventional breakpoints can be set.

This is not normaly a problem on our own sites but when we in this case incorporate their components in our pages we have to verify if the error we get is due to something in our page or in their code.

Comment 1

[:Gijs (he/him)]

Thank you for your report.

The setting of breakpoints by line is by-design. As-is, this bug is invalid, as as you say, Pretty Print is designed to do precisely what you ask for. If pretty print is somehow broken for you, you should really file a bug on that issue. However, as things are now, it's probably best to morph this bug (which I will do now), but that will require better steps to reproduce and/or at least mentioning the error message you're getting.

In summary, could you:
0) include the error message you purportedly get when enabling pretty print;
1) list more specific steps to reproduce (including when and how you open the debugger, when and how you enable pretty print, and how you set the breakpoint);
2) test whether this problem occurs on Firefox 2 as well, or if this is a regression.

Comment 2

[David Mårtensson]

I went over old links and found this.

This is still an issue.
Version: "You are running Venkman version 0.9.87.4."

I have tried pretty print again.

When I open a file on the same example as before I can get a list of many parts with line number ti the right.
This was the url for the example
http://aspnetajax.componentart.com/control-specific/datagrid/features/ajax_caching/webform1.aspx

These parts is pretty printed when opened with pretty print and without pretty print they cannot be opened.

But the main file is never pretty printed and it seem like there is a loot of code that is unavailable with pretty print and also, with everything split up in different tabs its impossible to get any feel for the code.

Try the second ComponentArtScriopt.axd in the list and open the first SetProperty and compare to the full file.

Many of the parts is named [SetProperty] and one example when opened contains

     function () {
         return nodesArray().length;
     }

This is obviously an anonymous function that is stored in a property, but which property? That is not shown, not event which object the property belongs to.

Is there a way to get the full source pretty printed?

If not, then pretty print is useless for these types of files and thereby the debugger to.

I know that the original developer probably have files in a better format, but when we try to use the component and get an error, we still need to be able to trace the code to identify if this is an error due to bad input or if it is en error in their code that we can point them to.

Should Pretty Print work on whole files or is the current result intended?

Comment 3

[James Ross]

Pretty Print works by taking the compiled JavaScript and turning it back into source code; any non-JavaScript will be lost, each top-level function is turned into a separate script so they're separately pretty printed, and the top-level script (containing the functions) is not available because the JavaScript engine throws this away as soon as it has run (as the page loads).

There is no way for the debugger to go from a function to the property you happened to assign it to (statically), but certain source code layouts are interrogated to guess names when the functions don't have them: the [SetProperty] name is one such guess. I don't know if the guessing would have worked better without the JS being compacted.

Comment 4

[David Mårtensson]

Ok.

Thats bad as I got the recomendation to use pretty print to be able to set breakpoints, but if it does not include all script thats impossible.

That means that the debugger is useless on compacted code :(

Cited from first reply 
"Pretty Print is designed to do precisely what you ask for."

But thats not correct if not all the javascript is retained.

Do you have any suggestion to where I should turn to try to get a solution to this? Any 3rd party addons that can reformat the jacascript directly on load before venkman sees it?

Comment 5

[BMO Automation]

Component is obsolete so resolving bugs as INCOMPLETE