Debugging a third-party site with WebStorm and PHPStorm

From IntelliJ-Wiki

Jump to: navigation, search

The possibility to debug JavaScript is vital for Web developers. With WebStorm and PHPStorm, such debugging becomes quite easy. After we have got certain experience in debugging a simple application deployed on a local Web server, let's get further and debug a real third-party site. For this purpose, we will retrieve the source code of the instant.js site that illustrates the capabilities of javascript instant image effect tool in supplying various canvas for pictures. We will arrange the captured code in a WebStorm project and debug it from the IDE.



  • You are working with WebStorm or PhpStorm, version 2.1 or higher. JavaScript support in WebStorm and PHPStorm is identical. Although this tutorial uses WebStorm, you can successfully repeat all the described steps in PHPStorm.

Note: JavaScript debugging is also available in IntelliJ IDEA and RubyMine, version 2.5 or higher.

  1. JavaScript Support
  2. JavaScript Debugger
  • The JetBrains Firefox extension that supports JavaScript debugging from WebStorm and PhpStorm. The extension will be installed automatically when you initiate a JavaScript debugging session for the first time.
  • No specific JS libraries are required. You are welcome to use any JS libraries you need.

Preparing contents for remote debugging

We do not have access to the sources of the site, so we cannot download it through a remote host configuration. However, we can capture the code underlying each page through the View page source functionality and save it in a local file with the name of the page. Next, we can easily reproduce the tree of application sources locally. Finally, we will map the local copies to their remote originals.

Application structure

The application sources are accessible through the following URL addresses:

  • - the starting page.

Creating a project

Let's start from the very beginning and create a project to arrange the application sources in. Launch WebStorm and choose Create New Project on the Welcome screen (Image 1):

Image 1. Welcome Screen.

In the Create New Project dialog box that opens (Image 2), give a name to the new project (1) and specify the project folder (2). Type the path to the project location manually or click the Browse button (3) and choose the relevant folder in the dialog box, that opens. In our example, the project name is debug_netzgesta and it is located in the C:\MY_PROJECTS\JAVA_SCRIPT_PROJECTS parent folder.

Image 2. Create New Project: specifying project name and location.

When you click OK, WebStorm opens the new project. As you can see (Image 3), it is just an empty folder:

Image 3. New empty project.

Populating the project

Now let's fill our new project with contents. As you can see from the application structure, the is the URL address of the document root, under which there are two folders:

  1. /instant/
  2. /cvi/scripts/

If we declare the local project root folder as the counterpart of the server document root, then it becomes clear that we need a project with two subfolders /instant/ and /cvi/scripts/.

Creating the folder structure

With the Project tool window having the focus (Image 4), press Alt+Insert, choose Directory (1) on the pop-up menu, and type the folder name (2) instant:

Image 4. Creating a folder.

Accordingly, with the project root folder in focus, press press Alt+Insert again, choose Directory on the pop-up menu, and type the second folder name cvi. Then create a scripts subfolder under cvi. Upon pressing OK, the project shows (Image 5) the root folder debug_netzgesta (1) with subfolders instant (2), cvi (3), and cvi/scripts (4):

Image 5. Two empty folders added.

Adding files to the folders

Now let's populate our folders with files and copy the application source in to them. Let's start with the instant folder and create a file instant.js in it (Image 6). Select the instant (1) folder in the Project tool window, choose New (2) on the context menu or press Alt+Insert. Then choose JavaScript File (3) on the pop-up menu, and type the file name (4) instant.js:

Image 6. Adding a file to a folder.

Next, create the index.php and cvi_text_lib.js files in the instant folder. When creating the index.php file, specify the full name index.php in the New File dialog box.

So doing, populate the cvi/scripts folder with the following files:

  • accordion.js
  • fixed.js
  • overlay.js
  • projectmenu.js
  • unsaveable.js

Finally, the project tree should look as follows (Image 7):

Image 7. Project tree completed.

Transferring the sources

Now that we have reproduced the site structure locally in our project, let's fill the local files with the corresponding contents from the site. This procedure is identical for all files. Here we will consider one example, and you will be able to repeat it for all the files in the project.

1. Open the page in the browser.

2. On the context menu, choose View Page Source (Image 8):

Image 8. Accessing the source code underlying a Web page.

3. In the new browser window that opens (Image 9), select the entire the source code underlying the Web page by pressing Ctrl+A.

Image 9. Page source.

4. Copy the selection (Image 10) to the clipboard by pressing Ctrl+C.

Image 10. Web page source selected.

5. Open the file index.php in the editor by double-clicking it in the Project tree. Paste the contents of the clipboard into the file by pressing Ctrl+V.

So doing, page by page, pull the source code that underlie the pages to the local files with the names of the corresponding pages.

Creating run/debug configuration for remote debugging

Unlike local debugging, for which the default run/debug configuration is provided, we’ll have to create one for remote debugging ourselves. This is how it’s done:

Press Alt+Shift+F9, and then press 0 to choose Edit configuration on the pop-up menu (Image 11):

Image 11. Open the Edit Configurations dialog.

In the Run/Debug Configurations dialog box, click the File:add.png toolbar button (1), then select in sequence JavaScript Debug (2) and Remote (3) on the context menus (Image 12):

Image 12. Creating configuration JavaScript Debug - Remote.

In the right-hand pane of the dialog box (Image 13), specify the main debug configuration settings:

  • In the Name (1) text box, type debug_netzgesta.
  • In the URL to open (2) text box, specify the URL address for accessing the starting page of the application. Type
  • From the Browser (3) drop-down list, choose Firefox to have the starting page opened in this browser.
Image 13. Creating configuration: specifying browser and URL.

Synchronizing files on server with local copies

When a remote file with a JavaScript injection is opened, the debugger tells the IDE the name of the currently processed file and the number of the line to be processed. The IDE opens the local copy of this file and indicates the line with the provided number. This behaviour is enabled by specifying correspondence between the URL addresses to access files and folders on the server and their local copies. This correspondence is called mapping. Mappings can be defined per files as well as for entire folders.

We will map the entire local project folder to the URL address of its counterpart on the server (Image 14'). In the Remote URLs of local files (1) area, click the Remote URL (3) field next to the project root node C:\MY_PROJECTS\JAVA_SCRIPT_PROJECTS\debug_netzgesta (2) and type the following URL address (4):

Image 14. Creating configuration: specifying mappings.

The debug configuration is ready, click OK to save it.

Setting breakpoints

Now let’s set breakpoints to our JavaScript. This is most easy – just click the left gutter at the line you want the script to suspend (Image 15):

Image 15. Breakpoints in JavaScript set.

Let's set two breakpoints. The first breakpoint (1) will make the program stop as soon as the JavaScript is called. The second breakpoint (2) is set inside a loop that draws canvas around pictures.

Starting the debugging session

Now that all the preliminary steps are done, it’s time to proceed with the debugging session itself (Image 16). From the Edit Configurations (1) drop-down list, select the newly created debug_netzgesta (2) configuration and click the File:debug.png (3) button on the toolbar.

Image 16. Starting a debugging session.

If you are launching the debugger for the very first time, WebStorm will install an extension that enables JavaScript debugging in Firefox and notify you about it (Image 17):

Image 17. Installing an extension to Firefox.

After launching the debugger, Firefox will inform you that the extension has been installed.

Note: adding the JetBrains extension results in adding the Debug in WebStorm command to the context menu of the pages in Firefox.

WebStorm starts the debugging session.

Examining the debugging information

When the debugging session is launched, the starting index.php page (Image 18) opens in the browser.

Image 18. Empty starting page.

When the PHP interpreter calls the instant.js script, the focus in the WebStorm editor switches to the file instant.js and the Debug tool window opens (Image 19). The first breakpoint is hit immediately, because we have set it at the script start, so the program execution suspends at once. The cursor in instant.js is positioned at the beginning of the line with the breakpoint hit (Image 19). The line is marked with a blue stripe in the background:

Image 19. The first breakpoint in instant.js reached.

Let’s now step through the script. Actually, you can use the stepping buttons on the toolbar of the Debug tool window, but since you are working in a keyboard-centric IDE, use the handy shortcuts, depending on your debugging algorithm. For example, you can press F7 to step line by line. However, let's press F9 to resume the program and have it work automatically till the next breakpoint is hit (Image 20). The second breakpoint (1) is set next to the first line of the loop that draws images and canvas. The loop runs until all the images and canvas from the theimages array are rendered. If you hover the mouse over theimages (2), the contents of the array are shown in the pop-up window. The current loop execution number is stored in the variable i. As you can see, now i=0 (3).

Image 20. Second breakpoint hit. Analyzing the functionality of the loop.

Let's switch to the browser (Image 21 ) and see what images have been rendered by now. As you can see, the page shows images without canvas.

Image 21. Loop execution 1. All images rendered without canvas.

If you now press F9, the program will resume and the loop will run once again. The Debug tool window (Image 22) shows that now i=1:

Image 22. Loop execution 2. Debug tool window: i=1.
Image 23. Loop execution 2. First image supplied with canvas.

As you step through your application, the corresponding information appears in the Debug tool window, and the browser displays the script output step by step (Image 24):

Image 24. Intermediate result of script execution.

Finally, when the program execution is completed (Image 25), the debugging session data is cleared (1) and the numbers.html page displays the entire script output (2):

Image 25. Final script execution output.

That’s it with debugging a script hosted on a remote server.

See also

Personal tools