Way to launch the debugger:
- You can also start the browser with the -venkman command line option. This will launch Venkman instead of a browser front end. Other programs, such as the mail client or web browser can then be started from Venkman's Window menu.
- You can type x-jsd:debugger in the URL bar. Currently, this is the recommended way to launch Venkman from within Mozilla Firebird or Phoenix. Note that you can bookmark this URL, and file it wherever seems to make sense to you.
Venkman support the 'debugger;' statement, but we must have Venkman already opened.
To start debugging, click on the Stop button, and refresh the page.
|Shift + F11||/finish||step out|
Press ESC to give focus to the input box below the Interactive Session
If it looks like some panels are missing, or are in the wrong place, just type in "/restore-layout factory" into the console to have it restore back to the default layout.
After configuring the layout to your to your preference, you can save the default layout with View -> Save Default Layout Now.
If a panel is missing, you can bring it back by View -> Show / Hide
/help /help commandname
How to set the evaluation context?
If we have multiple tabs, or iframes, we may have to tell Venkman which iframe or tab is to be used as the evaluation context. To set the evaluation context for Venkman, right click on appropriate entry in the "Open Windows" panel, and select "Set as Evaluation Object"
How to disable debugging of certain functions?
In the "Loaded Scripts" panel, right click on the function name, and select "Don't Debug"
Hard breakpoints versus future breakpoints:
A breakpoint acts much like the debugger keyword. It causes Venkman to halt, but only if the line is reached by executing code. A breakpoint will only be used, if the line it's on is executed. So it goes without saying, that you can only set them on lines with actual code.
There exists two kinds of breakpoints. Hard breaks can only be set inside functions, and acts much like the debugger keyword, causing Venkman to halt, just before the line is executed. The other kind, is called a future breakpoint. This represents a "promise" from Venkman, to halt as soon as possible. Future breakpoint is mostly used in top level code.
Hard breakpoint is indicated with a line in the far left grayest margin. Cicking once on the "-" and it should change into a red "B".
If you want to remove a breakpoint, it's as simple as clicking the "B", so that it turns into a "F", and then once more, so it turns into a "-", thus clearing the breakpoint.
Once a file has loaded, and is statically sitting there, you can only set hard breaks inside of functions. If you need to set something which exists only in the top level, you can set a so called "future" breakpoint. Which basically means, that if a file, from the same URL as the current one is loaded, and if executable code exists at the line number where a future breakpoint was set, Venkman will halt as soon as possible (I know it sound weird, but I don't really get it either.)
You don't really have to care much about the difference between hard and future breaks, just that future break are the only one you can set in the top of a script. It might seem confusing, with both types of marks, but really, it's not.
Each breakpoint has a series of properties attached, these properties allow you to create "intelligent" breakpoints, whose behavior is governed by conditions you decide.
To change the behavior of the breakpoint, make sure that the breakpoint is set, and right click on the same line, and select 'Breakpoint Properties'. This display a dialog which allows you to change various property for the breakpoint.
One of the interesting checkbox is "When triggered, execute …". When you check the check box, you'll be allowed to fill in the body of a function that will execute in the scope of the function, where the breakpoint is located (the function is called trigger). Start with filling this into the body of the function.
The "Stop if result is true" is more interesting though. It basically allows your breakpoint to become a conditional breakpoint.
You might also have noticed that a parameter count is passed to the function. This parameter indicates the number of times the breakpoint has been passed.
Note, that count begins at 1, and goes up from there (this will only work, if the radio button "Stop if result is true" is checked of course). You can during debugging, reset the count so far, to whatever you wish, by using the "Trigger count" box, and just entering whatever number you want to.
The final radio button option is a an option that let's you return "early" with the result now (in stead of letting the function run it's course, and return normally.)
The "Pass exceptions to caller", determines, if exceptions throw in the function trigger, get passed to your code or not. This is a great way of testing if your script handles errors well.
The last check box, "Log result", simply means, that asides from doing the radio button choice, it will also write the result to the Interactive Session. For this to really work, you need to actually return something.
Feature that Venkman has:
- Break at next statement.
- Pretty Print (This can be accessed via View -> Pretty Print, or you can right click on source and select Pretty Print)
Known issues / Wishlist / Missing features:
After using the debugger, you close the debugger (by clicking the X button), and close all firefox instance. You would think that firefox would be completely shutdown, but it does not. It remains running in the background. Next time you start firefox, and launch the debugger, firefox does not open the debugger window. To get around this, you must kill firefox via the Task Manager.
- Unable to view the location of the file.
- Unable to say "I am not interested in debugging these files ever", and have it persistant across restarts.
- Unable to say "I am not interested in debugging timeout", and have it persistant across restarts.
- Venkman should be in the status bar like Firebug.
- Should we merge Venkman and Firebug together? In firebug, you can find the value of the variable by mousing over it. Is this overkill?
For every event that happen on a page, save the event object, the event handlers (there could be more than one, the name of the event handler function, the url of the source file, line number, and lines of code that get executed), and snapshot of element, and all attributes of all existing elements. There should be a hotkey for starting and stoping this capturing. Firebug has a feature for tracking event. It would be nice if Venkman have it as well.