How can I debug and test websites

Debugger

The JavaScript Debugger allows you to step through the JavaScript code, viewing and changing its state in order to find errors in the code more easily.

It can be used to debug code locally in Firefox, or remotely - for example on a Firefox OS device or a Firefox on Android. This tutorial assumes you are editing local code, but most of it applies to remote debugging as well. For the differences, see the remote debugging instructions.

To open the debugger, simply select "Debugger" from the Firefox web developer submenu (or from the Tools menu if you are using the menu bar or if you are on Mac OS X), or by using the keyboard shortcut (the "shortcut" ) Control-Shift-S (Command-Option-S on Mac) on the keyboard.

The toolbox appears at the bottom of the browser window. The debugger is activated by default. This is what it looks like when it is opened for the first time:

And this is the view during the debugging process:

In this tutorial, we'll first take a quick look at the debugger's user interface and then describe how to perform some common debugging tasks.

The debugger user interface

The user interface (UI) is divided into four areas, which we will look at one after the other:

  • the toolbar
  • the source list pane
  • the source pane
  • the variable list ("variables pane")

The source code file list

On the left you will see a list of all the JS source files that have been loaded from the current page. Any of these can be selected to be debugged.

The source files are grouped under headings that indicate where they were loaded from. Here is an example of a source code file list when a page from developer.mozilla.org is loaded:

The file names and domains match the following tags in the source code of the page:

In the source code file list, you can simply click on one of the files to view and examine it in the source code area.

Breakpoints that you set by clicking next to a line of code appear under the file name.With the checkbox you can switch breakpoints on and off. By right-clicking on a Brakepoint entry in the list, you can display a context menu with which you can

  • activate or deactivate individual or all breakpoints (or all breakpoints until the clicked)
  • Define conditions under which the execution should be interrupted at this point (or change these conditions if they are already set)

By clicking on the "eyeball" you can switch the "black boxing" for a certain source on and off (e.g. prevent jumps in JavaScript libraries). You can find more information about this under "Black box a source".

Source code area

The currently loaded JavaScript file is displayed here. Breakpoints ("Breakpoints", in the picture "Breakpoint Set") are the blue circles next to the line numbers, while breakpoints at which the code execution was currently stopped have a green arrow inside the circle ("Breakpoint Hit"):

In the source code area, the following tasks can be performed using the context menu:

  • Set breakpoints
  • set conditional breakpoints
  • add a watchdog expression for the selection
  • use the script search or search with the help of such a filter

Toolbar

The toolbar consists of four parts:

  • a button bar with which you can control the movement through the script (pause / continue, jump in, leave, execute)
  • a visualization of the "Call stack" (call list)
  • the script filter
  • Buttons with which the variable list and the debugger settings can be collapsed and collapsed

The four buttons on the left have the following functions:

  • Pause / continue (F6): Interrupts the script execution or continues it. If the switch is shown blue and "pressed" as above, the execution is interrupted - either because you pressed this button yourself or because it has reached a breakpoint. ("Pause / Resume")
  • To run (F7): Executes the current line of JavaScript code and skips to the next. ("Step over")
  • Jump in (F8): Jumps to the function that is called in the current JavaScript line. ("Step into")
  • leaving (Shift-F8): Lets the script run through (and execute) until the current function has ended. ("Step out")

The visual representation of the "Call stack" (list of code interruptions at which a level deeper was jumped into a new function) shows the list of all code positions where function calls have led to the current breakpoint. This list can be used to find out how the program "got to the current position".

By clicking on the entries, the jump point is displayed in the source code area and you can see where the jump was made from. At the same time, the variable values ​​at the time of the respective function call are displayed in the variable list. This can often be used to find out whether and why parameters were passed incorrectly and where the actual error occurred. Even if functions are called from different places in the code, the stack can be used to find out which case it is.

Scriptsuche

With the script search ("script filter") you can search through all three debugger areas. You can prefix the search term with one of the following special characters in order to use various special functions.

PrefixFunction
NothingBrowse scripts that appear in the source code list.
!Search for the search term in all files.
@Search only for function definitions in all files that contain the term.
#Search for the term only in the file currently displayed in the source code area.
:Jump to a line number (in the file currently displayed in the source code area).
*Browse variables displayed in the variable list.

These options are displayed in a popup when you click in the search field, and they are also accessible from the context menu in the source code area. The special characters can also be combined to make more precise searches: "file.js: 12"For example, opens file.js and jumps to line 12."mod # onLoad"searches for the term" onLoad "in all files that contain" mod "in their name. You can jump from one result to the next with the Return / Enter key.

Debugger settings

At the right end of the toolbar there are two more buttons. The first toggles between showing and hiding the variable list. The second one can be used to switch between different debugger settings:

With this option enabled, the debugger will automatically detect minified JS files and pretty-print them.

Auto Prettify Minified Sources

If this option is switched on, the debugger automatically finds minimized JavaScript files and displays them in a readable form.

Pause on exceptions

Automatically interrupt script execution when a JavaScript exception is thrown.
Ignore caught exceptions

If this setting is set (default setting) and "Pause on exceptions" is activated, the system will only be interrupted for errors that are not caught. This setting is standard because it can be assumed that caught exceptions will be handled properly in the program.

New option in Firefox 26.

Show panes on startupIf this option is activated, the debugger variable list is displayed as soon as the debugger is activated for the first time.
Show only enumerable propertiesEnabling this option adds a "Filter variables" search box to the variables panel, so that you can filter the displayed list of variables.
Show variables filter boxDo not display non-enumerable JavaScript properties
Show original sourcesEnabling this option will make the debugger use source maps, if they are available, to display the original source for code which has been combined, minified, or even compiled to JavaScript from a language like CoffeeScript.

Variable list

In the variable list you can see which values ​​the variables currently have at a certain point in the program - and you can even change them manually for experiments and then let the script continue to run:

Monitor variable values

The variables are grouped by scope: in the function scope you can see the (standard) values ​​of and and local variables that were defined in the function (in the example: and).

The situation is similar with global variables that have been defined on the top level of the JavaScript file (i.e. not in functions) - in the figure, for example, but also standard variables such as and.

Objects can be opened and closed with the small arrow to the left of them. This makes their properties (and functions) and their values ​​visible.

If you move the cursor over the variables, a tooltip with further information is displayed - when rollover over the object, for example, " enumerable writable"is displayed. More details on the meaning of these properties under.

The displayed variables can be filtered - either by using the "*" modifier in the script search, or by entering the filter text (#,!, ...) in front of the search term in the search field, if this option is in the debugger settings activated.

Change variable values

Variable values ​​can easily be changed manually by clicking on the values ​​and entering another value. If you click on, for example, the variable value of, you can change the greeting and let the program continue to work with this value.

Watch expressions

Watchdog expressions are expressions that are evaluated each time code execution is stopped. With the help of monitoring expressions, you can get an overview of values ​​that are not displayed directly in the variable list - such as certain properties of an object that are currently required to understand the code sequence (see example in the figure). Or variables in the code that have not been declared and are therefore not displayed in the list by the debugger - or values ​​that can only be read with a getter method (such as) or jQuery expressions such as.

Simply click on "Add watch expression" above the variable list and enter an expression exactly as you would in the code at the current position to get a value. This value is then calculated at each program stop as you go through the code and displayed in the list like the values ​​of the variables.In this way you can watch how certain values ​​change while running through the program. At the moment when a change takes place, the monitoring printout is briefly highlighted in yellow so that you can see the changes out of the corner of your eye while you are reading the program code.

Of course, you can also monitor several expressions in the list at the same time. To remove an expression, simply click on the small "x" that appears to the right of the monitoring expression when you move the cursor over it.

How can I...?

open the debugger

Simply select "Debugger" in the web developer submenu (or click in the Firefox menu bar under "Tools> Web developer> Debugger" if you are using Mac OS X or have the menu bar displayed). Alternatively also with Control-Shift-S (or. Command-Option-S on Mac).

find a source file

Source files are easy to find: When the debugger is open, all JavaScript source files are listed in the source code list on the left. If the list is too long, it is often easier to use the script search in the top right corner.

Find codes in a file

To find a function, to search for a keyword or to speak in a certain line in the code that is open in the source code area, you can use the special filters of the script search.

Set breakpoint

To set a "breakpoint" in a file that is open in the source code area:

  • Either click on the line number next to the line of code where you want to interrupt
  • or open the context menu via the code line itself (right-click, Ctrl-click) and select "Add Breakpoint" there.

Each breakpoint is displayed in three places in the debugger:

  • in the source code list under the file name
  • the line in the source code area is marked with a blue ring next to the line numbers
  • the gray bar to the right of the source code scrollbar shows all breakpoints as small blue boxes (on the scale of the scrollbar, i.e. breakpoints that are currently not visible in the source code area)

In the screenshot below you can see breakpoints in lines 7 and 65 of the JavaScript file:

Set a conditional breakpoint

In order to set a conditional breakpoint at which a break should only be made in certain cases, open the context menu in the relevant line and select "Add conditional breakpoint". A Boolean expression can simply be inserted in the text field that then opens. The syntax is exactly the same as in the parentheses of an if statement:

To change the "condition" or to add a condition to a "normal" breakpoint afterwards, simply open the context menu on the breakpoint and select "Configure conditional breakpoint":

Deactivate breakpoint

To "disable a breakpoint" without deleting it:

  • either: Remove the tick in the checkbox next to the breakpoint entry in the source code list
  • or: via the context menu above the entry in the source code list and there click "Disable breakpoint"

Follow the program sequence

If the execution of the code is stopped at a breakpoint, you can follow the processing of program lines and individual commands step by step. To do this, use the four buttons (pause / continue, jump in, exit, execute) in the upper left corner of the toolbar:

The four buttons on the left have the following functions:

  • Pause / continue (F6): Interrupts the script execution or continues it. If the switch is shown blue and "pressed" as above, the execution is interrupted - either because you pressed this button yourself, or because it has reached a breakpoint. ("Pause / Resume")
  • To run (F7): Executes the current line of JavaScript code and skips to the next. ("Step over")
  • Jump in (F8): Jumps to the function that is called in the current JavaScript line. ("Step into")
  • leaving (Shift-F8): Lets the script run through (and execute) until the current function has ended. ("Step out")

Source Maps

JavaScript source code is often combined from several files and the result is "minified" (compressed) in order to optimize server load and load times. The loaded JavaScript is more and more machine-generated, for example from languages ​​such as CoffeeScript.

By using source maps, the debugger can "map" the currently executed code to JS files, which are more easily readable for humans - that is, show the corresponding places in the human-readable files, which makes debugging a lot easier.

To do this, you have to tell the debugger that there are such source maps for the code used by clicking on "Show original sources" in the debugger settings (gear icon at the top right):In order for this to work, you must have specified a mapping URL in a comment in the source file that tells the debugger where the alternative files are located. Such a comment in the JavaScript file should look like this:

Check variable values

If the debugger interrupts program execution at a "breakpoint", the current values ​​of the variables can be viewed at this point in the code. They are displayed on the right in the list of variables:

The list of variables is on the right. The variables are shown in blocks, filtered according to scope ("scopes"). Objects can be expanded if you want to see individual properties (see variable values ​​above). The display of the variables can also be filtered using a "*" at the beginning of the script search input field ("filter expression"):

Assign different values ​​to variables

If the execution of the code was interrupted at a breakpoint ("breakpoint"), the values ​​can be changed in the variable display of the debugger. Simply click on the current variable value - the value becomes an input field and can be changed immediately:

Observe an expression

You can monitor the value of a Javascript expression with the "Monitor Expression" function in the variable bar.

Debug mobile devices

Debugging mobile devices is dealt with in remote debugging.

Hiding source files ("black boxing")

Many websites and programs today use frameworks such as jQuery, Ember or Angular and 99% of the time you can simply assume that their code will work. Most of the time we don't want to see the internals of these libraries when debugging - we hide them and treat them as black boxes. Black boxing eliminates the tiresome digging into library files (for example with each loops or triggering events) and we can concentrate on our actual code.

Black boxing can also be switched on and off for individual files by clicking on the breakpoint symbol ("eyeball": Eyeball) to the left of the source file in the list. Many sources can also be hidden by using the command in the developer toolbar (Shift + F2):

When a code file is hidden:

  • ... all breakpoints in this source file are deactivated.
  • ... the debugger also leaves out this code when stepping through the code.
  • If "pause on exceptions" is enabled, the debugger does not stop when an error is thrown in a hidden ("black boxed") source file - instead it waits until (and: whether) it enters the call stack comes back to a non-hidden point.

Debug browser add-ons

The following debug options are available in the Chrome environment:

chrome: //browser/content/debugger.xul or

in version 23 beta, chrome: //browser/content/devtools/debugger.xul:

  • window.addEventListener ("Debugger: EditorLoaded") - is called after loading the read-only script panel.
  • window.addEventListener ("Debugger: EditorUnloaded")

Associated files:

  • chrome: //browser/content/devtools/debugger-controller.js
  • chrome: //browser/content/devtools/debugger-toolbar.js
  • chrome: //browser/content/devtools/debugger-view.js
  • chrome: //browser/content/devtools/debugger-panes.js

Unfortunately, there is still no API to evaluate expressions in the debug area or to mark page elements that are referenced by variables in the debug area. (Work in progress at the moment, see also bug report 653545.)

See also: