How do you debug JavaScript programs? The most primitive method is to use alert() to print content on the page, and a slightly improved method is to use console.log() to output content on the JavaScript console. Well, using these two methods has indeed solved many debugging problems of small JavaScript scripts. However, it would be a pity to not use developer tools that are becoming more and more powerful in Chrome. This article mainly introduces the JavaScript breakpoint setting and debugging functions, that is, the Sources Panel (formerly called Scripts). If you are proficient in various Java debugging techniques in Eclipse, the concepts here are similar. The Chrome version used when writing this article is 25.0.1364.172.
Basic environment
To the left of SourcesPanel is the content source, including various resources in the page. Among them, it is divided into Sources and Content scripts. Sources are various resources contained in the page itself. They are organized according to the domains that appear on the page, which is what we need to pay attention to. Asynchronously loaded js files will also appear here after loading. Content scripts is a Chrome extension that is organized according to the extension ID. This type of extension is actually a resource embedded in the page, and they can also read and write DOM. Only developers who write and debug extensions like this should care about them. If your browser does not have any extensions installed, Content scripts will not see anything.
The middle main area of Sources Panel is used to display the contents of the resource file on the left.
On the right side of Sources Panel is the debugging functional area. The top row of buttons are Pause/Continue, Step-by-step, Step-by-step jump in, Step-by-step jump out, Disable/Enable all breakpoints. Below are various specific functional areas. This will be introduced later.
Note that the areas on both sides may shrink by default and not displayed on both sides. Click the telescopic buttons on both sides to display. When the left area is displayed, the default is to automatically shrink. Click the pin button next to it and it will not retract.
There are also some feature buttons at the bottom that are very useful.
Set breakpoints on source code
Through the content source on the left, open the corresponding JavaScript file, click the file line number and set and delete breakpoints. Each breakpoint added will appear in the Breakpoints list in the debug area on the right. Clicking the list breakpoint will locate the breakpoint in the content area. If you have multiple files and multiple breakpoints, it is very convenient to quickly locate breakpoints in the Breakpoints list.
There are two states for each added breakpoint: Activate and Disable. The breakpoints just added are all activated states, and the disabled state is to retain the breakpoint but temporarily cancel the breakpoint function. There is a check box before each breakpoint in the Breakpoints list, and unchecking will disable the breakpoint. Breakpoints can also be disabled in the right-click menu of the breakpoint position. You can also temporarily disable all added breakpoints on the button on the right ribbon, and click it to restore the original state.
Conditional breakpoint : Select "Edit Breakpoint..." in the right-click menu of the breakpoint position to set the condition to trigger the breakpoint, that is, write an expression, and the breakpoint will be triggered only when the expression is true. Check the environment call stack of breakpoints (Call Stack): When the breakpoint stops, the Call Stack in the debugging area on the right will display the method call stack where the current breakpoint is. For example, there is a function g() in which the function f() is called, and I set a breakpoint in f(). Then when I execute the function g() in the console, the breakpoint will be triggered, and the call stack will be displayed as follows:
The top is f(), and then g(). Each layer in the call stack is called a frame. Clicking on each frame can jump to the calling point of that frame.
In addition, you can restart the execution of the current frame on the frame using the right-click menu, that is, from the beginning of the frame. For example, on the frame of the function f(), the breakpoint will jump to the beginning of f() and re-execute, and the variable value in the context will also be restored. In this way, combining functions such as variable modification and code editing, you can repeatedly debug in the current frame without refreshing the page and triggering the breakpoint again. View variables
Below the Call Stack list is the Scope Variables list, where you can view the values of local and global variables at this time. Execute the selected code
During breakpoint debugging, you can use the mouse to select the variable or expression you want to view, and then right-click the menu to execute "Evaluate in Console" to see the current value of the expression. The "Interrupt/Continue" button on the top of the debugging area on the right side of the JavaScript statement to be executed next time has a function. When there is no breakpoint triggered, clicking this button will enter the "Preparation" interrupt state. The next time the page executes the JavaScript statement, it will automatically interrupt, such as the code that will be executed when a click action is triggered. Temporarily modifying JavaScript code. We usually get used to this loop when debugging code: modify the code → refresh the page → recheck. But in fact, the content in the JS file can be temporarily modified in Chrome. Save (Ctrl+S) can take effect immediately, and re-debug it immediately with Console and other functions. But please note that this modification is temporary, and the refresh page modification will be gone.
Break point in exception
You can see the button below the interface. It is a switch that sets whether the program is interrupted when it encounters an exception when it is running. Clicking this button will switch between 3 states:
By default, no interruption will be encountered
All exceptions will be interrupted, including captured situations
Only interrupt if an uncaught exception occurs
Mainly explain the difference between state 2 and state 3
try{
throw 'a exception';
}catch(e){
console.log(e);
}
The code in the above try will encounter an exception, but the catch code behind can catch the exception. If all exceptions are interrupted, the code will automatically interrupt when it is executed to the throw statement that will produce an exception; and if it is interrupted only when it encounters an uncaught exception, then it will not interrupt here. Generally, we will be more concerned about encountering uncaught exceptions.
Set breakpoints on DOM elements
Sometimes we need to listen to a certain DOM being modified without caring about which line of code is modified (or there may be many places that will be modified). Then we can set breakpoints directly on the DOM.
As shown in the figure, in the Elements Panel of Elements Review, you can set three breakpoints in the right-click menu on an element: after the child node modifys its own attributes and modifys its own node is deleted, the DOM breakpoint will appear in the DOM Breakpoints list on the right side of the Sources Panel. Once executed to make corresponding modifications to the DOM, the code will stop there, as shown in the figure below.
XHR Break Point
There is an XHR Breakpoints in the debugging area on the right. Click + and enter the string contained in the URL to listen to the Ajax request for the URL. The input content is equivalent to the URL's filter. If nothing is filled in, listen for all XHR requests. Once the XHR call is triggered, it will break in the place where request.send() is requested.
Trigger breakpoint by event type
The Event Listener list in the debug area on the right, where various possible event types are listed. Check the corresponding event type, and it will automatically interrupt when the JavaScript code that triggers the event of that type.
Debug shortcut keys
The shortcut keys in all development tools can be found in the settings in the lower right corner of the interface. F8, F10, F11 or Shitf+F11 is generally used when debugging breakpoints, but function keys such as F10 may conflict with the system's default shortcut keys. It doesn't matter, they can be replaced by Cmd+/, Cmd+', Cmd+; , Shift+Cmd+; respectively. //@ sourceURL Name the code produced by eval. Sometimes some very dynamic code is created in the current Javascript context in the form of a string through the eval() function, rather than loading as a separate js file. In this way, you will not find the file in the content area on the left, so it is difficult to debug. In fact, we just add a line "//@ sourceURL= name" at the end of the code created by eval to name this code (the browser will treat this special form of comments specifically), so that it will appear in the content area on the left, just like you load a js file with a specified name, you can set breakpoints and debug. In the figure below, we execute a piece of code through eval and use sourceURL to name it dynamicScript.js. After execution, this "file" appears in the content area on the left, and its content is the content in eval. You can also take a look at this example of naming the dynamically compiled CoffeeScript code:
var coffee = CoffeeScript.compile(code.value)+ "//@ sourceURL=" + (evalName.value || "Coffeeeeeeee!");
eval(coffee);
In fact, //@ sourceURL can not only be used in eval code, but any js file or even the code entered by Javascript Console can be used, with the same effect! The format code (Pretty Print) button is used to reformat the messy code into beautiful code, such as some compressed js files that are basically unreadable or debugged. Click the format and then unformat it. Before beautification
Beautified reference: Chrome Developer Tools official documentation