Chrome Developer Tools (DevTools)
Remote Debugging with Proxies
IE Developer Tools (f12 Developer Tools)
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 from the Chrome Menu
Running from the Webpage
Running with Shortcut Keys
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.
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 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 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.
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 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.
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.
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.
Add the files to be put in the Blackbox by navigating to [Settings] Menu → Blackboxing menu.
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.
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.
[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.
[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.
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.
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.
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.
This section will explain using Safari remote debugging functionality to debug webpages on iOS devices.
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.
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.
As one of Fiddler’s main features, traffic capture allows developers to monitor the traffic of a certain project as shown 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.
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 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.
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.
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 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.
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.
Sessions are composed of five tabs, and the five tabs are explained in the following sections.
The overview tab provides a wholistic view into the session, and provides information on request, response, timing, and etc.
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 is used, not for presenting the session information in a table format, but for comparing sessions to other sessions.
The Chart tab presents the session’s timeline in a bar graph format.
This tab is used to make notes on sessions.
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.
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.
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.
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.
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.
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.
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.
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.
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.
|2019. 05. 07|