By the way, different versions of Chrome's devtools may be slightly different, except for the digitally incrementing version number, which includes the stable version, beta, Dev development, Canary, and the originator. Chromium version of these branches. The browser used by bloggers and the fast core of most dual-core browsers on the market are based on chromium development. From the stability aspect, the Stable>beta>dev>canary>chromium, while the updated speed is exactly the opposite chromium>canary>dev>beta>stable. If you want to use the latest devtools, then I suggest you can use the Canary version, Canary version can and existing other versions of the Chrome browser do not interfere with each other coexistence.
The Run Control button group is located at the top right of the source panel, through which you can step through our code. These buttons are:
Continue (F8): Is what we normally commonly called the release. When a breakpoint is encountered while the current execution is paused, click this button to continue executing the program until the breakpoint is hit again.
Step Over (F10): Generally we say the single step refers to this, one line of execution of the current code. A bit different from "stepping" is that when executed to a method, "Step Over" returns the execution result of the method directly, and the breakpoint executes to the next line of the current code snippet. "Step into" will enter the code inside the method. In general, we debug, the first step through, look at the output of the method, if the output is wrong, then step into the method of internal debugging.
var a;a = dosomething (); Console.info (a);
As this code above, the first line performs "Step Over" and "stepping", the effect is the same. In the second line, "Step over" skips the inside of the DoSomething method, causing the breakpoint to execute to the third row. Now look at the value of variable A, and if a returns as expected, continue debugging. If a and expected deviations, then "step into" the second line to the inside of the DoSomething method. Continue to debug with step over and walk in.
Step Into (F11): In the general code, and the "stepping" effect is the same, on the line of code executed by the method, "step into" will go to the inside of the method definition.
Step Out (SHIFT+F11): When accidentally pressed into or we need to jump out of the current method, "step out" can directly let the breakpoint back to the calling parent method. (Before knowing this, bloggers are stepping out of the way)
Toggle Breakpoint Status : You can quickly toggle the Enable/deactivate state of a breakpoint. This button can be implemented when we do not need a breakpoint for the moment and want the code to execute directly. Disabling a breakpoint does not delete the breakpoint that has been hit, and when you need to continue using the breakpoint, click again to enable the breakpoint.
In parentheses are the shortcut keys for these single-step debugging buttons, which are easier to debug with shortcut keys.
Debugging with breakpoints
With the checkbox in front of the breakpoint listed in the "breakpoints" sidebar, we can enable/disable breakpoints, and the blue flag in front of the deactivated breakpoint will be lighter.
Click on the breakpoints listed in the "breakpoints" sidebar to quickly locate the line of code for the break point ~
Click the blue flag that has been hit on the breakpoint to remove the breakpoint.
Right-click on the breakpoint Blue flag to display the breakpoint related menu: Continue to Here, Remove Breakpoint, Edit breakpoint ..., Disable breakpoint.
Select "edit breakpoint..." in the right-click menu of the breakpoint to set the breakpoint as a conditional breakpoint, or you can right-click on the line number without the breakpoint and select "add Conditional breakpoint" to set the conditional breakpoint. In the input box of a conditional breakpoint, you can enter any expression that returns TRUE or false. Breakpoints only work when the expression is true to pause the current program execution. When our breakpoint hits a loop or a frequently triggered event, the conditional breakpoint can be used to avoid unnecessary pauses in the program (do not press F8 and accidentally miss the breakpoint).
The blogger took several batches of interns to see the interns. Debug programs often insert alert or console output variable content in code, accidentally commit code or release, put these debugging statements also brought up. In fact, the conditional breakpoint can be done without modifying the code file to pop the window or command line output, as long as the alert or console written to the conditions of the condition variables can be ~
The right "call stack" will show the current call stack, click on the different parts of the call stack, you can quickly navigate to the part of the code, we can be more convenient to trace up to the wrong part of the code.
About "async" official documentation does not seem to be carefully said, bloggers find the code of the test, the Refreshreslist method is called by a click event, Refreshreslist method initiated an AJAX request from the server to obtain some data to display on the page. If "async" is not checked, you can only see the call stack that the Ajax request came back from, and you cannot see the process of calling Refreshreslist from the click event and executing the AJAX request. (if at first did not tick "async", enter the breakpoint after the tick is not effective, need to enter the breakpoint again, to see the effect)
One of the purposes of debugging code is to find out where the code is going wrong, Devtools provides "pause on exceptions", which pauses the execution of the code when an exception occurs. The exception breakpoint is opened by clicking on the icon at the top right, and when the icon changes, the exception breakpoint is turned on. When an exception breakpoint is turned on, you can choose to catch only the exception caught by the catch statement or catch all exceptions by ticking the "pause on caught exceptions". Note that in different browsers may "pause on caught exceptions" the same way, in the blogger's Speed browser, is selected in the form of a checkbox, in some browsers, may be by clicking the icon again to open.
The right Dom breakpoints of the source panel will display the currently playing Dom breakpoint, which will be triggered when the DOM changes, and we can see the existing DOM breakpoints here, about the 3 Dom breakpoints in Devtools Note 2. Friends who want to know can take a look at Chrome development tools Learning Notes (2).
Below the DOM breakpoint, "XHR breakpoints" We can set breakpoints on XHR requests here to monitor page-initiated AJAX requests. In Devtools Note 4, we talked about debugging network requests through the networking tool, where the XHR breakpoints allow us to debug from the point of view of the code.
Open "XHR breakpoints", the default is another breakpoint for all XHR requests to pause, we can right-click to select "add Breakpoint"adds a breakpoint to the XHR request for the URL that contains the specified text (if the contents are empty, all XHR requests are matched, as with any xhr effect).
In the source panel, we can see that the code where the exception occurred is marked, and the cursor moves up to see the error message, which helps us to look at some of the more foolish code bugs.
Debug Chrome Extensions
reprinted self-Technical blog http://www.cc-lab.cn/chrome-dev-tools-5/
Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.
Chrome Development Tools Learning notes (5)