JavaScript breakpoint Debugging method without relying on the browser console

With the gradual and powerful browser, most of the code debugging can be done by the browser to bring some debugging tools to solve. However, for some special cases still can not enjoy the browser's powerful debugging capabilities, such as QQ client embedded Web debugging (although QQ can now be compiled developer tools, but still need to install the specified package or tool), the abnormal browser web, mobile scene embedded and other scenarios.

With the gradual and powerful browser, most of the code debugging can be done by the browser to bring some debugging tools to solve. However, for some special cases still can not enjoy the browser's powerful debugging capabilities, such as QQ client embedded Web debugging (although QQ can now be compiled developer tools, but still need to install the specified package or tool), the abnormal browser web, mobile scene embedded and other scenarios. Based on this scenario, our team has introduced weinre under Nohost and has been widely used. But Weinre has certain limitations, can only do console.log and Dom view, etc., can not support breakpoint debugging. There are already some descriptions of the old articles here, which can be found in http://www.webryan.net/2013/04/talk-about-remote-debugging-on-mobile-phone/.

This paper focuses on the ability of not relying on browser console, the ability to debug breakpoints simply by JavaScript, providing another way of thinking and solving problems. First will give the use of tools, so that we have perceptual knowledge, and then explain the specific implementation principle.

"Test Use"

1, cmd command to execute "NPM install Breakpoint-g" (NPM installation does not repeat,-G for the global installation and register the bin command)

2, cmd command line Execution "Breakpoint" (will give the use of help, and start the test directory by default: can be accessed directly through the URL);

3. Open two modern browsers, such as Chrome and Safari, and turn on the two URLs of the prompts respectively.

OK, three simple steps can be tested in the browser. Here's how this ui/index.html works:

is not very simple:), let us give a practical example;

"Practical Use"

"Parameter description"

usage:breakpoint-d Htdocsdir-r Passbyrule

-d Specifies the local static directory, where the HTML file head is injected with a debug script.

-r Specifies the pass-through rule, which is usually used to pass the CGI request to the current server, and if it needs to be passed to the specified server, it needs to be pointed out in the local Hosts file;

-H when there are multiple network cards, you can use-h to specify an IP;

The breakpoint will enable 3 ports locally, 80 for the Access Service, 8000 for the controller, and 8500 for file rewriting.

"Practical Examples"

Suppose our domain name is: abc.com; local static files (HTML, CSS, JS, etc.) directory is: e:\svn\trunk\htdocs\, then you can through the "breakpoint-d E:\svn\trunk\htdocs" Forward all requests to the local directory, for example: Http://abc.com/a.html returns the contents of the local directory E:\SVN \trunk\htdocs\a.html.

However, it is not possible to access the abc.com directly in the browser, you need to first point to the local IP via tools such as Fiddler (refer to step 1).

Then access http://10.64.53.85:8000/ui/index.html to open the controller; Access: http://abc.com/a.html access to resource content.

It is not difficult to find that the access content has been successfully local, and automatically put a debug script on the head, this is done.

But often when debugging, we want some files to access the resources of the current network resources or other servers, this time, can pass the-R parameter to match the corresponding request. For example: abc.com point to the local IP, you want all requests under abc.com/cgi-bin/to be sent to the current network. Then only the "breakpoint-d e:\svn\trunk\htdocs\-R cgi-bin" can be executed.

"Principle Analysis"

How do I use JavaScript to debug breakpoints?

The core problem of breakpoint debugging is to let the script in a line of code to pause execution, then Aleksander Kmetec classmate gives the solution is: by adding a breakpoint function in front of each line of JavaScript. The breakpoint function blocks the browser with Ajax synchronization properties .

Then the JavaScript changes before and after the situation is as follows:

Before modification	After modification
var a = 1; var B = 2; function Test () { var c = ' init '; c= ' Change '; }	Break (); var a = 1; Break (); var b = 2; Break (); function Test () { Break (); var c = ' init '; Break (); c= ' Change '; }

It's really smart to start synchronizing Ajax requests in the break function to determine the breakpoint location and block the browser from executing the script behind it.

"Breakpoint Structure Diagram"

1. Launch Web request via browser;

2, request through fiddler and so on to our rewrite service, rewrite the service according to the request link to process the process. If a regular rule with-R is matched, it is forwarded directly to the active network server, otherwise the content in the local-D directory is requested.

3, the content of the transmission is not processed directly, the other content will be judged: 1, the HTML file will default in the first line of the head to add the script scripts (the script includes debugging required methods, such as break ();) 2, JS file will be added in front of each line of script break ();

4. Rewrite the service to return data to the browser

5. When the browser executes JS, it encounters a break (), then initiates a synchronous XHR request that blocks the execution of the browser.

6. If a breakpoint is set through the Debug service UI interface, the debug service will hold the XHR request in Break () until the Debug service UI issues a new command (such as Skip, next line, etc.)

JavaScript breakpoint Debugging method without relying on the browser console