Debugging
Debugging is a process of tracking down the cause of an error and correcting it. For JavaScript, a language that spans various platforms, different debugging tools exist for different platforms, and each tool operates differently, giving the impression that “JavaScript debugging is difficult.” However, the fact of the matter is that JavaScript tools have come a long way, and developer tools found in modern browsers provide features and UI designed to facilitate the debugging process. This guide will mainly be based on Chrome Developer Tools (Chrome DevTools,) the most widely used debugging tool, but will also explain Internet Explorer (IE) debugging tools (F12 Tools) as well.
Table of Contents
Chrome Developer Tools (DevTools)
Chrome Development Tools are currently the most frequently used debugging tool, and offers more functionalities than any other debugging tool in the web. Even Opera browser, based on Chrome’s open source project Chromium, uses the same developer tools. This guide explains the main panels and features of Chrome v70 developer tools. Other features can be found on the official webpage.
Running DevTools
-
Running from the Chrome Menu
- [More Tools] → Select [Developer Tools]
-
Running from the Webpage
- Right click → Select [Inspect]
-
Running with Shortcut Keys
- Ctrl + Shift + I (Windows)
- Cmd + Opt + I (Mac)
Sources Panel
Sources panel allows developers to visually check which resource files are loaded onto the page, and provides a script debugging feature to edit and test the currently loaded script. Image below is the Sources panel, and the loaded resource folder tree, the source code, and various buttons and feature information can be found in the left, center, and in the right, respectively.
Detailed explanations of the image above are as follow.
- Click on the line number to set the breakpoint. The code will stop running once it meets the breakpoint.
- Once the code is paused, different buttons on the right can be used to control the flow and proceed to step debugging.
- While debugging, variables or objects of interest can be registered to Watch, and their value changes can be monitored at different breakpoints.
- Records of function call stacks, starting at the initial loading of the page to the end of all execution, monitored, and can be accessed by clicking on the Call Stack pane.
Setting Multiple Breakpoints
While breakpoints can be set by clicking on the line number, when debugging, it is also common to want to set a breakpoint not at a specific location, but at a specific situation. Chrome Developer Tools provide multiple ways to set breakpoints, even if it is hard to pin down a particular line.
Event Listener Breakpoints
Event Listener Breakpoints can be used to debug a certain situation in which a particular event has happened. For example, if a breakpoint for an onClick event is set, the event handler will stop once a click event happens inside of the DOM. Event Listener Breakpoints can be set from the Sources Panel → [Event Listener Breakpoints] and click on the target event, and once the breakpoint is set, the execution will stop when the set event occurs.
Conditional Breakpoints
Conditional breakpoints are similar to defining breakpoints on the Sources panel, but it differs that the code stops running only under given conditions. Conditional breakpoints are used, for example, to check if a certain value is given to a frequently occurring function or to check only the last element of the loop. Conditional breakpoints can be set by right clicking on the target line number → [Add conditional breakpoint] and designing the conditional.
If a desired condition is entered, the code will stop running only if the conditional is evaluated as true.
Break on DOM Changes
A breakpoint can be set to pause the program once a particular change has been made to the DOM. The program will only break if there is a change to the target DOM or to its child DOM. The breakpoint can be configured by right clicking on the target element in the Elements panel → [Break on] and choosing one of the three given options.
Ajax Breakpoint
Ajax Breakpoints can be used to find the piece of Ajax code that sends a request to a certain target. For example, it can be used effectively to determine which code is making the request when the source of the call is uncertain. By specifying the target pattern to match in the Source Panel → [XHR/Fetch Breakpoints], the code will stop at the point where the matching Ajax call is made.
Configuring the Blackbox Extension
Sometimes when step-debugging, the debugging point moves from the source code to the library code. While it is not entirely impossible for the library code to contain errors, usually, developers must correct their own logic. By using the Blackbox extension, library code can be hidden during the step debugging process. Also, files that are not the target of debugging process (external files) can be put in the Blackbox to hide them from the call stack, which would allow developers to focus on debugging their own codes in the call stack. There are two ways to configure the Blackbox.
Configuring from Context Menu
Open the files to put in the Blackbox from the Sources Panel and click on [Blackbox Script] from the right-click menu. Or, the [Blackbox Script] can be selected from right clicking on the file from within the Call Stack.
Configuring from the Settings Menu
Add the files to be put in the Blackbox by navigating to [Settings] Menu → Blackboxing menu.
Memory Profiling
In Performance and Memory Panels, critical information that affect the overall performance of the program can be found. For more detailed information on performance, refer to the [FE Guide] Performance. This chapter will discuss enhancing the program's performance by memory profiling. There are three different types of memory profiling that can be done on the Memory Panel. Let’s explore and use these options.
Heap Memory Profiling
When a JavaScript file runs, values like variables, objects, and closures are collected in the Heap memory, and its life cycle is maintained by the garbage collector. Garbage collectors periodically release memory that is no longer used, and do not release the memory even if it just has one reference pointing to it. Such remaining memory cause leakage, inevitably damaging the performance. Heap snapshot profiling method can be used to monitor the current Heap memory.
The image above is a comparison between two different heap snapshots. Snapshot 1 is recorded when the page has just loaded, and Snapshot 2 is taken after running some code after it has finished loading. By changing the item boxed in red, in the Snapshot 2 window, to “Comparison”, it allows developers to compare the two memory states with the second snapshot as the base. Such method can be used to speculate possible causes of irregular spikes and unreleased memory.
Using Timeline to Monitor Memory Allocation/Release
[Allocation Instrumentation on Timeline] can be used to monitor and record how the memory usage fluctuates as the page operates. The image below is an example of using timeline to record memory, and the blue bar represents newly allocated memory. With this information, valid speculations on the progression of memory management, like whether memory is leaking or increasing, or whether garbage collection is working properly, can be verified.
Finding the Point of Memory Allocation
[Allocation sampling] records the point of memory allocation. As in image below, it shows memory allocation logs for each function, and lists all functions according to allocated memory to make it easier for developers to spot functions that are using too much memory.
Mobile Debugging
It can feel crippling when trying to debug a webpage executed on a mobile device, only to realize that the developer tools cannot be executed on a mobile device. Thankfully, with the help of remote debugging functionalities provided by Chrome and Safari, pages operating in mobile browsers and web views can be debugged on the PC. Android devices and iOS devices can be debugged using Chrome and Safari, respectively.
Android Webpage Debugging
This section of the guide will explain using the Chrome remote debugging feature to debug a webpage on an Android device. Note that to debug web views, it needs further configuration within the application, so refer to this related document on configuring webviews for debugging.
Preparations
- Chrome v32 or above
- Android v4 (ice cream sandwich) or above
- Chrome installed on the Android device
- Android USB driver installed in the developer PC (for Windows)
- USB cable to connect to the Android device
Preparing the Android Device
- [Settings] → [Developer Options] → [Enable USB Debugging]
- Connect to the PC using a USB cable
Using the Developer PC to Debug
On the PC, open the Chrome Development Tools, and select [More tools] → [Remote devices].
If everything is set up, the connected device information will be presented on the left, as in the image below, and the link hosted on device’s Chrome can be monitored.
To start debugging, click the [Inspect] menu from the page to debug.
iOS Webpage Debugging
This section will explain using Safari remote debugging functionality to debug webpages on iOS devices.
Preparations
- Device with iOS 6 or above
- Mac with the OS installed
- Cable to connect the device to the Mac
Preparing the iOS Device
- Enable [Web Inspector] from [Settings] → [Safari] → [Advanced]
- Connect the device to the Mac
Using the Developer PC to Debug
Open Safari from the Mac, and configure [Safari] → [Preferences] → [Advanced] → [Show Develop menu in menu bar].
Doing so will create a Developer menu, and can use it to monitor the webpage running on the device as shown below. If the device does not appear, make sure that the safari versions match for both the Safari on the device and the Safari on the Mac, and if they are not the same, update so that they are.
Clicking on the target webpage will start the developer tool as shown below, and then developers can now debug for pages on the iOS device.
Remote Debugging with Proxies
Proxy tools like Fiddler and Charles can be used to manipulate certain packets to receive different replies from the server or to swap out remote JavaScript files on the server for a local file for remote testing. Proxy tools monitor PC’s network requests and responses and can manipulate the transmission with the server by placing breakpoints in said requests and responses. Proxy tools also allow developers to intercept and substitute files of a package that is already live on the server with different files. This guide will use Fiddler and Charles to monitor network traffic and to manipulate server transmissions. More detailed explanations about other features of Fiddler and Charles can be found on their official documentation.
Fiddler
Fiddler can be used to monitor network traffic records and to change the response from a server on a certain request. Fiddler can be downloaded from the official website, and does not need special configuration.
Traffic Capture
As one of Fiddler’s main features, traffic capture allows developers to monitor the traffic of a certain project as shown below.
However, since it captures every traffic on the project, it could complicate the debugging by inundating the process with data. Therefore, it is recommended to use the filtering functionality to only capture the necessary traffic. The below is an example of capturing traffics only on JavaScript files.
Changing Response Values with AutoResponder
AutoResponder is one of Fiddler’s most prized features, and it can change the response value of certain requests. Using AutoResponder, developers can substitute files like JavaScript and CSS codes that are already distributed with whichever file developers want. For example, say a developer wants to temporarily edit the config.js file from site A. To do so, first, save the edited version of config.js, and enable AutoResponder by checking the box like in the image below.
When AutoResponder is enabled, choose which request to change from the traffic area in the left, and press the [Add Rule] button to add a response rule.
It is also possible to declare the request using regular expression (regex,) and this related article explains it in detail.
If the request configuration is all done, set up the response rules by clicking on the response field as shown below.
Clicking on [Find a file] will automatically search for a file to replace the response. Now, select the edited version of config.js file, and press [Save]. Then, if the browser is reloaded, it can be seen that the designated file has replaced the response. If the change did not happen, try clearing the browser cache, and try again.
Commonly Reported Problems
If the PC shuts down without properly exiting from Fiddler, the next time the browser opens, it may throw out a similar error as shown in the image below. In this case, try running Fiddler again and exiting properly.
Charles
Charles is currently the most popular Proxy tool for the OSX. Charles, like Fiddler’s AutoResponder, also has a Map Local/Map Remote features and session debugging features. It supports HTTP and HTTPS, and its most unique characteristics are the Sequence tab that analyzes sessions according to the sequence and the Structure tab that analyzes sessions according to the directory.
Installing
While the download files can be found at the official website, it is a premium license, and require users to pay for service. When installed, running Charles will automatically initiate a Proxy. If not, navigate to [Proxy] → [Proxy Settings] menu and check that the HTTP Proxy Port is not being used in the computer for any other applications. Also, for Mac, make sure that [Enable Mac OS X Proxy] in Mac OS X tab is enabled. If the computer is running a VPN or is using a browser plugin VPN, the session will not be captured.
The Session Log
Charles provide two ways to monitor the session logs--the Sequence tab and the Structure tab. Use the two tabs appropriately for different situations. Each tab’s characteristics are explained below.
Sequence Tab
Sequence tab shows the session logs in a chronological order, like Fiddler. Sequence tab allows developers to see all of the detailed information on each request organized in a table format.
Structure Tab
The sessions captured while monitoring the traffic are organized in a tree with respect to the relative location to the domain. As shown in the image below, the data organization is very intuitive since it is categorized by domains. To the left, is a list of domains, and users can view the specifics by clicking on each domain, which will appear on the right. If same request occurs, it is captured and saved in the last folder.
Structure tab is recommended, since it is common in JavaScript for a single domain to corrupt the entire project. This is because it eliminates the possibility of confusing the API, and will also allow users to find the issued session faster.
Detailed Look into the Sessions
Sessions are composed of five tabs, and the five tabs are explained in the following sections.
Overview Tab
The overview tab provides a wholistic view into the session, and provides information on request, response, timing, and etc.
Contents Tab
Contents tab provides detailed information on the session requests and responses. The upper view shows the request contents and the lower view shows the response content. While the single file request may be simple, for data like JSON, it provides an organized format of in-depth information.
Summary Tab
Summary tab is used, not for presenting the session information in a table format, but for comparing sessions to other sessions.
Chart Tab
The Chart tab presents the session’s timeline in a bar graph format.
Note Tab
This tab is used to make notes on sessions.
Using Map Local to Change the Response
Similar to Fiddler’s AutoResponder, Map Local allows users to send the server’s response to a designated local file. First, find the file in the session to be replaced with a local file. As an example, the basic_dummy.js file will be replaced with a local file as presented below.
When the Map Local is selected by right clicking on basic_dummy.js, the Edit Mapping window, which allows users to select the file to replace the response with, appears. Here, click on the [Choose] button to select the replacement.
The same can be done using the Map Local Setting window in [Tools] → [Map Local]. Check Enable Map Local, and click on the [Add] button to add mapping content.
Using Map Remote to Change the Request
Charles allows certain requests to be substituted with another. While it is similar to Map Local, but the underlying concept differs that Map Remote changes the request entirely, instead of registering a substitute file. Similarly to Map Local, to access the menu, choose Map Remote from the right click menu, and the Edit Maptting window will appear. In the lower view, fill out the information to change the Map To information.
The same can be done from Map Remote Settings, which can be accessed by [Tools] → [Map Remote]. Check Enable Map Remote, and clikc on [Add] button to add new mapping rules.
IE Developer Tools (F12 Developer Tools)
IE7 and Below
Debugging tools for IE7 and below are not provided. Therefore, a separate tool called Debug Bar is required. Debug Bar is a free tool provided by the Companion.js that enables developers to use the console object on IE to debug. To install, either refer to the download menu on the official page or the install manual.
IE8 ~ IE11 and Edge
From IE8 and onwards, developer tools (F12 tools) are included by default. Therefore, the tools can be accessed from the browser’s tools menu or by pressing the F12 button on the keyboard (hence the nickname.) When the user opens the developer tools, it will appear on the bottom of the browser in a split screen. Since the developer tools found in IE8 and above are similar to the tools in, previously explained, Chrome, this guide will not deal with specific details of F12 tools.
Note Reference: IE Developer Documentation, DevTools Guide (Edge)
Virtual Machine
In 2013, Microsoft put out modern.IE in order to test multiple versions of IE in different platforms. modern.IE is a tool that provides virtual machines to run IE6 to IE11. However, since the launching of a new browser Edge in 2015, the modern.IE seems to have been deprecated. Attempting to connect to the modern.IE will redirect to Virtual Machine Image Download page, and the versions supported in the virtual machine changed to from IE8 to IE11. Also, an image of Edge’s own virtual machine has been added. As of September 2018, virtual machine tools in the market are VirtualBox, Vagrant, VMware, Hyper-V, and Parallels.
Virtual machines can be used to debug IE projects in non-Windows environment, or to test a certain version of IE. This guide demonstrates the process of using Virtual Box to simulate an IE8. While Virtual Box can be used for free for running simple tests, other features are included in a paid-for premium version.
Installing VirtualBox
VirtualBox can be installed from the official website by selecting the operating system for the development environment. Each virtual machine is about 1 Gigabyte or more in memory, so make sure to place it in a directory with plenty of room.
Downloading the Virtual Machine
Choose the operating system and the version of IE in Virtual Machine Image Download and select “VirtualBox” in the Select Platform prompt to download the virtual machine.
Running VirtualBox
Execute the virtual machine image in VirtualBox. Click on the Import Virtual System menu like below to select the previously downloaded virtual machine image file.
Configure the virtual machine’s RAM with consideration of the current PC’s RAM.
When everything is set up, it will take a few minutes for all of the system to finish configuring.
When all is well, the selected virtual system will be added, as shown below, and can be ran by double clicking on it.
Afterword
This guide dealt with debugging methods and tools ranging from Chrome’s developer tools to using Proxy tools to debug remotely. As environments in which to web functions are increasing in number, the debugging methods and forms are following its trend. This guide will hopefully enable its readers to effectively debug solely with the materials found in this guide.
This document is an official Web Front-End development guide written and maintained by NHN Cloud FE Development Lab. Any errors, questions, and points of improvement pertaining to this document should be addressed to the official support channel (dl_javascript@nhn.com).
| Last Modified |
|---|
| 2019. 05. 07 |