Script InSight: Using Models to Explore JavaScript Code from the Browser View Peng Li and Eric Wohlstadter University of British Columbia {lipeng,wohlstad}@cs.ubc.ca Abstract. As Web programming standards and browser infrastructures have matured, the implementation of UIs for many Web sites has seen a parallel increase in complexity. In order to deal with this problem, we are researching ways to bridge the gap between the browser view of a UI and its JavaScript implementation. To achieve this we propose a novel JavaScript reverse- engineering approach and a prototype tool called Script InSight. This approach helps to relate the semantically meaningful elements in the browser to the lower-level JavaScript syntax, by leveraging context available during the script execution. The approach uses run-time tracing to build a dynamic, context- sensitive, control-flow model that provides feedback to developers as a summary of tracing information. To demonstrate the applicability of the approach we present a study of an existing open-source Web 2.0 application called the Java Pet Store and metrics taken from several popular online sites. Keywords: Reverse-Engineering, Software Maintenance, Rich Internet Applications, JavaScript. 1 Introduction The user interface (UI) is a key aspect of most Web sites. As Web browser programming standards such as JavaScript and the W3C Document Object Model (DOM) have matured, the implementation of UIs for many sites has seen a parallel increase in complexity. These rich Web applications have the advantage of providing a seamless and interactive experience for end-users. However, these applications also require more development effort to build and maintain than older Web UI. As the Web has become more interactive and complex, we are researching a more interactive, model-based approach for Web application reverse-engineering and debugging. Most existing work on modeling of UI-intensive Web applications focuses on development but not specifically maintenance and debugging. For example, [1] introduces a framework for the integration of presentation components in mashup applications. Trigueros et al. present a model driven approach, the RUX-Model, for the design of rich Internet applications [2]. Valderas et al. introduce an approach to support the coordinated work between Web UI designers and analysts during the development of a Web application [3]. In [15], Rossi et al. use a model-driven approach to transform conventional Web applications into rich Internet applications M. Gaedke, M. Grossniklaus, and O. Díaz (Eds.): ICWE 2009, LNCS 5648, pp. 260 – 274, 2009. © Springer-Verlag Berlin Heidelberg 2009 Script InSight: Using Models to Explore JavaScript Code from the Browser View 261 by applying refactoring at the model level. Meliá et al. propose a model-driven development methodology which extends a traditional Web modeling methodology for use with the Google Web Toolkit [16]. Some research in software maintenance and reverse-engineering has been used for testing of Ajax applications [14], but not specifically for interactive debugging, as we focus on in this paper. As with any complex software development task, creating a user interface requires an iterative cycle of design and implementation. Starting with an initial design, an interface would first be prototyped and then refined over several cycles into a final product. At each stage, some design decisions may need to be reconsidered and the implementation adjusted accordingly. The UI might even evolve after the release of an application in order to fix bugs or add new features. After each cycle, developers can determine the quality of the current application by executing the implementation and evaluating the UI appearance and functionality in a Web browser. If they notice anything wrong with the browser view of the UI, they would need to map the problem back to some part of the implementation, to enact the appropriate change. Unfortunately, reversing engineering a rich interactive Web page and mapping the appearance or behavior of some element in the Web page to the corresponding implementation can be quite difficult. This is because today’s Web UI are stateful and reactive. Their appearance and behavior vary over time based on mutations of state made from JavaScript. This problem is exacerbated by the fact that a developer working on the UI might not have written the original code for all parts of the Web site. In that case, they may need to dig through unfamiliar code to try and reverse- engineer the source. This process is especially difficult since code for some systems on the Web is poorly documented. As described by Hassan et al. [4], “Currently, [code] inquiries can only be answered by scanning the source code for answers using tools such as grep, consulting documentation, or asking senior developers.” In order to deal with this problem, we are researching an interactive approach to bridge the gap between the browser view of a UI and the JavaScript piece of the implementation. This is motivated by the fact that the browser view is usually easy to understand and semantically meaningful, unlike the implementation code. We want to help developers use the live UI as an entry-point into the lower-level implementation details. To achieve this, we propose a novel JavaScript tracing approach. To a first approximation, when a change is made by a script statement to a visual DOM attribute (e.g. color, height, etc...), we record a link between the effected browser element and the code responsible. The intuition is that a developer can now easily navigate through the code by hyperlinking directly from browser elements. However, a basic implementation of this approach is vulnerable to two problems. First, mapping semantically meaningful events, such as the mutation of a visual attribute directly to a location in the source code (e.g. a statement) may not be helpful, because that one statement might be reused for several different purposes in the execution of the script. For example, informing a developer that an attribute was changed in a “setter” method for that attribute provides little useful information. The “setter” method could be called many times in the execution of a script, in different contexts, for a variety of different purposes. 262 P. Li and E. Wohlstadter For this reason we are researching the use of context-sensitivity to help provide a mapping. A context-sensitive approach captures not only the execution of individual statements, but also the state of the call stack, which can help distinguish between multiple executions of the same statement. Second, the visual behavior of a Web page (e.g. the way widgets are animated) is often achieved by a set of coordinated DOM attribute mutations. For example, a button’s appearance may change to reflect the button is active when a panel is closed, and change again to reflect it is inactive when the panel is open. The changes to the button appearance and panel appearance have a causal relationship. If a developer wants to change the widget animation they may need to make coordinated changes to several DOM nodes. For this reason we are researching the use of a custom control- flow model, the DOM mutation graph (DMG), that developers can use to leverage their understanding of these causal relationships, seen in the browser view, in mapping from the browser view to script source code. To demonstrate our approach of using this DMG to explore script code, we present a study of an existing open-source Web 2.0 application called the Java Pet Store [9] and metrics taken from several popular online sites. We show how this model is used to understand animation effects in the application which require coordinated changes to several page elements. The metrics taken from other pages provide evidence supporting the need for context-sensitivity in Web application reverse-engineering. The rest of the paper is organized as following: Section 2 presents a motivating example and an overview of our approach, Section 3 presents technical details, Section 4 presents metrics from online sites, Section 5 presents a further detailed example, and in Section 6 we give related work and we conclude in Section 7. 2 Motivating Example and Approach Overview In order to motivate our approach, we use a case-study of an existing open-source Web application called Java Petstore 2.0 (henceforth, JPS). This online pet store offers the end-user several interactive widgets to control the application, as shown in Figure 1. Here we see the “Catalog Browser” page from which the end-user can browse prospective pets. This one page alone makes use of 1232 lines of JavaScript code spread across 3 files. Running down the left-side of the page is an accordion bar. This widget is a stylized tree-view for browsing categories of pets and their respective sub-categories (e.g. the specific kinds of cats). The table rows for the categories interactively expand/ deflate to reveal/hide sub-categories when the mouse cursor is positioned/removed from a category name. This “accordion” animation requires JavaScript programming to mutate the DOM in an event loop. In Figure 1, the “Cats” row is expanded and the other categories remain deflated. Consider the perspective of a front-end developer who would like to make changes to this Web page. They have to remember or understand how the 1232 lines of code is mapped to elements of the page and their behavior. In the original JPS, each accordion row is expanded and deflated at a constant speed. Here we consider a change task where a front-end developer wants to change the animation to accelerate at a decreasing/increasing rate when a row is expanding/ deflating. During the task the developer is confronted with three problems. Script InSight: Using Models to Explore JavaScript Code from the Browser View 263 Fig.