Using Chrome to debug JavaScript breakpoint settings and debugging skills, chromejavascript

Using Chrome to debug JavaScript breakpoint settings and debugging skills, chromejavascript

How did you debug the JavaScript program? The most primitive method is to use alert () to print content on the page. A slightly improved method is to use console. log () to output content on the JavaScript console. Hmm ~, These two methods solve the debugging problems of many small JavaScript scripts. However, it is a pity that the developer tools with more powerful Chrome functions are not used. This article mainly introduces the JavaScript breakpoint setting and debugging functions, namely the Sources Panel (previously called Scripts ). If you are proficient in various Java Debugging techniques in Eclipse, the concepts here are similar. The Chrome version used for writing this article is 25.0.1364.172.

Basic Environment

The left side of SourcesPanel is the content source, including various resources on the page. It is divided into Sources and Content scripts. Sources is the various resources contained in the page. It is organized according to the domain that appears in the page. This is what we need to pay attention. Js files asynchronously loaded will also appear here after loading. Content scripts is an extension of Chrome, which is organized according to the extension ID. Such extensions are actually embedded in the page resources, and they can also read and write the DOM. Developers who write and debug such extensions need to care about them. If your browser does not install any extensions, Content scripts will not see anything.

The middle primary area of the Sources Panel is used to display the content of the resource file on the left.

The right side of the Sources Panel is the debugging function area. The top buttons are pause/continue, single-step execution, single-step jump-in, single-step jump-out, and disable/enable all breakpoints. Below are various functional areas. Later.

Note: by default, the area on both sides of the left and right may be scaled down and not displayed on both sides. Click the scaling button on both sides to display the area. When the area on the left is displayed, it is automatically scaled in by default. clicking the pin button next to it will not be scaled back.

Some Function buttons are useful at the bottom.

Set breakpoints on source code

Open the corresponding JavaScript file through the content source on the left, and click the row number of the file to set and delete the breakpoint. Each added breakpoint will appear in the Breakpoints list in the debugging area on the right. Click the breakpoint in the list to locate the breakpoint in the content area. If you have multiple files and multiple Breakpoints, you can use the Breakpoints in the Breakpoints list to quickly locate them.

Each added breakpoint can be activated or disabled. The added breakpoint is activated. The disabled breakpoint is retained but the breakpoint function is temporarily canceled. In the Breakpoints list, there is a check box before each breakpoint. If you deselect this check box, this breakpoint is disabled. You can also disable a breakpoint from the right-click menu. You can also click the button on the right of the functional area to temporarily disable all added breakpoints, and then click to restore the original state.

Conditional breakpoint: Right-click the Breakpoint position and select "Edit Breakpoint..." to set the condition for triggering the Breakpoint. the Breakpoint is triggered only when the expression is true. View the Call Stack of the breakpoint environment: When the breakpoint is stopped, the Call Stack in the right debug area will display the method Call Stack of the current breakpoint. For example, there is a function g () the function f () is called, and I set a breakpoint in f (). When I execute function g () on the console, the breakpoint is triggered, its call stack is shown as follows:

The top is f () and then g (). Each layer in the call stack is called a frame. You can click each frame to jump to the call point of the frame.

In addition, you can use the right-click menu on the frame to re-execute the current frame, that is, from the beginning of the frame. For example, if you Restart frame on the Frame of function f (), the breakpoint will jump to the beginning of f () and re-execute it. The variable value in context will also be restored. In this way, combined with functions such as variable modification and code editing, You can debug the current frame repeatedly without refreshing the page to re-trigger the breakpoint. View Variables

At the bottom of the Call Stack list is the Scope Variables list, where you can view the values of local Variables and global Variables. Run the selected code

During breakpoint debugging, you can select the variable or expression you want to view and right-click the variable or expression to execute "Evaluate in Console" to view the current value of the expression. The "interrupt/continue" button in the debugging area on the right of the JavaScript statement to be executed next time has another function. When the breakpoint is not triggered, click this button to enter the "prepare" interrupt state. The page will be interrupted automatically when the next JavaScript statement is executed, for example, the code that will be executed when a click action is triggered. We usually get used to temporary modification of JavaScript code when debugging code: modifying code → refreshing page → re-checking, such a loop. But in fact, Chrome can temporarily modify the content in the JS file, save (Ctrl + S) can take effect immediately, combined with the Console and other functions can immediately re-Debug. But note that this modification is temporary, and the modification will be gone after the page is refreshed.

Breakpoint in case of exception

You can see the button in the interface, which is a switch that sets whether to interrupt the program when an exception occurs. Click this button to switch between the three statuses:

By default, exceptions are not interrupted.

All exceptions are interrupted, including captured exceptions.

It is interrupted only when an uncaptured exception occurs.

It mainly explains the differences between status 2 and status 3.

Try {
Throw 'a exception ';
} Catch (e ){
Console. log (e );
}

The code in the above try will encounter an exception, but the catch code later can catch this exception. If all exceptions are interrupted, the code execution will automatically interrupt when an exception throw statement is generated. If it is interrupted only when an exception is not captured, it will not be interrupted here. In general, we are more concerned about situations where exceptions are not captured.

Set breakpoints on DOM elements

Sometimes we need to listen to the modification of a DOM, regardless of which line of code is modified (or it may be modified in many places ). Then we can set breakpoints directly on the DOM.

As you can see, in the Elements Panel of the element review, you can right-click an element to set breakpoints in three different situations: after the child node modifies its own attributes and modifies its own node to be deleted and selected, this DOM breakpoint appears in the DOM Breakpoints list on the right side of the Sources Panel. Once the DOM is modified, the Code stops there, as shown in.

XHR breakpoint

The debugging area on the right has an XHR Breakpoints. Click + and enter the string contained in the URL to listen to the Ajax request of the URL. The input content is equivalent to the URL filter. If nothing is specified, all XHR requests are listened. Once the XHR call is triggered, it will be interrupted at the location of request. send.

Trigger breakpoint by event type

The Event Listener list in the debugging area on the right. Various possible Event types are listed here. Select the corresponding event type. The JavaScript code that triggers this type of event will be automatically interrupted.

Debugging shortcuts

Shortcut Keys in all development tools can be found in the settings in the lower-right corner of the interface. During breakpoint debugging, F8, F10, F11, or Shitf + F11 are generally used. However, function keys such as F10 on Mac OS may conflict with the default shortcut keys of the system. It doesn't matter. They can be replaced by Cmd +/, Cmd + ', Cmd +;, and Shift + Cmd +. // @ SourceURL name the eval code. Sometimes some very dynamic code is created in the current Javascript context using the eval () function in the form of a string, instead of being loaded as an independent js file. In this way, you cannot find this file in the content area on the left, so it is difficult to debug it. In fact, we only need to add a line at the end of the Code created by eval "// @ sourceURL =Name"You can name this Code (the browser will treat this special form of comment) so that it will appear in the content area on the left, just as if you have loaded a js file with the specified name, you can set the breakpoint and debug it. In, we run a piece of code through eval and use sourceURL to name it dynamicScript. js. After the execution, the "file" appears in the content area on the left, and its content is the content in eval. You can also take a look at the example of naming the dynamically compiled CoffeeScript code:

Var coffee = CoffeeScript. compile (code. value) + "// @ sourceURL =" + (evalName. value | "coffeeeeeeeeee! ");
Eval (coffee );

In fact, // @ sourceURL can be used not only in eval code, but also in any js file or even the code entered on the Javascript Console. The effect is the same! The formatting code (Pretty Print) button is used to reformat messy code into beautiful Code. For example, some compressed js files cannot be viewed or debugged. Click format to cancel the format. Before beautification
Reference after beautification: official documents of Chrome Developer Tools