Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Kartik Bajaj

dblp:139/6958 · DBLP profile ↗
← Back
6ranked-venue papers
4as first author
0since 2021 · last 2017
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 6 · 4 first-authorDatabases, data management, data science and information retrieval · 1 · 1 first-author

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Software engineering, system software, and programming languages
4 papers
Software testing · 36% Program synthesis and code generation · 31% Empirical software engineering · 29%
Network and information security
1 paper
Web and mobile security · 100%

Topics — the 6 heaviest of 8, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Software testing
web application testing
0.422015
LED: Tool for Synthesizing Web Element Locators · ASE 2015
Synthesizing Web Element Locators (T) · ASE 2015
Empirical software engineering › mining software repositories
bug report analysis
0.312017
A Study of Causes and Consequences of Client-Side JavaScript Bugs · IEEE Trans. Software Eng. 2017
Software testing
fault analysis
0.312017
A Study of Causes and Consequences of Client-Side JavaScript Bugs · IEEE Trans. Software Eng. 2017
Empirical software engineering
mining software repositories
0.312017
A Study of Causes and Consequences of Client-Side JavaScript Bugs · IEEE Trans. Software Eng. 2017
Program synthesis and code generation
code completion
0.212014
Dompletion: DOM-aware JavaScript code completion · ASE 2014
Program analysis
static analysis
0.112017
A Study of Causes and Consequences of Client-Side JavaScript Bugs · IEEE Trans. Software Eng. 2017

Methods — techniques the papers use, named apart from their topics

manual bug report classification · 0.6example-based synthesis · 0.4constraint solving · 0.2pattern extraction · 0.2dynamic analysis · 0.2
YearPublicationVenuePosition
2017 A Study of Causes and Consequences of Client-Side JavaScript Bugs
abstract
Client-side JavaScript is widely used in web applications to improve user-interactivity and minimize client-server communications. Unfortunately, JavaScript is known to be error-prone. While prior studies have demonstrated the prevalence of JavaScript faults, no attempts have been made to determine their causes and consequences. The goal of our study is to understand the root causes and impact of JavaScript faults and how the results can impact JavaScript programmers, testers and tool developers. We perform an empirical study of 502 bug reports from 19 bug repositories. The bug reports are thoroughly examined to classify and extract information about each bug' cause (the error) and consequence (the failure and impact). Our results show that the majority (68 percent) of JavaScript faults are DOM-related, meaning they are caused by faulty interactions of the JavaScript code with the Document Object Model (DOM). Further, 80 percent of the highest impact JavaScript faults are DOM-related. Finally, most JavaScript faults originate from programmer mistakes committed in the JavaScript code itself, as opposed to other web application components. These results indicate that JavaScript programmers and testers need tools that can help them reason about the DOM. Additionally, developers can use the error patterns we found to design more powerful static analysis tools for JavaScript.
Frolin S. Ocariza Jr., Kartik Bajaj, Karthik Pattabiraman, Ali Mesbah 0001
IEEE Trans. Software Eng.2
2015 Synthesizing Web Element Locators (T)
abstract
To programmatically interact with the user interface of a web application, element locators are used to select and retrieve elements from the Document Object Model (DOM). Element locators are used in JavaScript code, Cascading stylesheets, and test cases to interact with the runtime DOM of the webpage. Constructing these element locators is, however, challenging due to the dynamic nature of the DOM. We find that locators written by web developers can be quite complex, and involve selecting multiple DOM elements. We present an automated technique for synthesizing DOM element locators using examples provided interactively by the developer. The main insight in our approach is that the problem of synthesizing complex multi-element locators can be expressed as a constraint solving problem over the domain of valid DOM states in a web application. We implemented our synthesis technique in a tool called LED, which provides an interactive drag and drop support inside the browser for selecting positive and negative examples. We find that LED supports at least 86% of the locators used in the JavaScript code of deployed web applications, and that the locators synthesized by LED have a recall of 98% and a precision of 63%. LED is fast, taking only 0.23 seconds on average to synthesize a locator.
Kartik Bajaj, Karthik Pattabiraman, Ali Mesbah 0001
ASE1
2015 LED: Tool for Synthesizing Web Element Locators
abstract
Web applications are growing fast in popularity and complexity. One of the major problems faced by web developers is writing JavaScript code that can retrieve Document Object Model (DOM) tree elements, and is consistent among multiple DOM states. We attempt to solve this problem by automatically synthesizing JavaScript code that interacts with the DOM. We present an automated tool called LED, to analyze the DOM elements, and synthesize code to select the DOM elements based on the DOM hierarchy as well as the nature of task that the user wants to perform. LED provides an interactive drag and drop support inside the browser for selecting positive and negative examples of DOM elements. We find that LED supports at least 86% of the locators used in the JavaScript code of deployed web applications, and that the locators synthesized by LED have a recall of 98% and a precision of 63%. LED is fast, taking only 0.23 seconds on average to synthesize a locator.
Kartik Bajaj, Karthik Pattabiraman, Ali Mesbah 0001
ASE1
2014 Dompletion: DOM-aware JavaScript code completion
abstract
JavaScript is a scripting language that plays a prominent role in modern web applications. It is dynamic in nature and interacts heavily with the Document Object Model (DOM) at runtime. These characteristics make providing code completion support to Java- Script programmers particularly challenging. We propose an auto- mated technique that reasons about existing DOM structures, dynamically analyzes the JavaScript code, and provides code completion suggestions for JavaScript code that interacts with the DOM through its APIs. Our automated code completion scheme is implemented in an open source tool called DOMPLETION. The results of our empirical evaluation indicate that (1) DOM structures exhibit patterns, which can be extracted and reasoned about in the con- text of code completion suggestions; (2) DOMPLETION can pro- vide code completion suggestions with a recall of 89%, precision of 90%, and an average time of 2.8 seconds.
Kartik Bajaj, Karthik Pattabiraman, Ali Mesbah 0001
ASE1
2014 Mining questions asked by web developers
abstract
Modern web applications consist of a significant amount of client- side code, written in JavaScript, HTML, and CSS. In this paper, we present a study of common challenges and misconceptions among web developers, by mining related questions asked on Stack Over- flow. We use unsupervised learning to categorize the mined questions and define a ranking algorithm to rank all the Stack Overflow questions based on their importance. We analyze the top 50 questions qualitatively. The results indicate that (1) the overall share of web development related discussions is increasing among developers, (2) browser related discussions are prevalent; however, this share is decreasing with time, (3) form validation and other DOM related discussions have been discussed consistently over time, (4) web related discussions are becoming more prevalent in mobile development, and (5) developers face implementation issues with new HTML5 features such as Canvas. We examine the implications of the results on the development, research, and standardization communities.
Kartik Bajaj, Karthik Pattabiraman, Ali Mesbah 0001
MSR1
2013 An Empirical Study of Client-Side JavaScript Bugs
abstract
Context: Client-side JavaScript is widely used in web applications to improve user-interactivity and minimize client-server communications. Unfortunately, web applications are prone to JavaScript faults. While prior studies have demonstrated the prevalence of these faults, no attempts have been made to determine their root causes and consequences. Objective: The goal of our study is to understand the root causes and impact of JavaScript faults and how the results can impact JavaScript programmers, testers and tool developers. Method: We perform an empirical study of 317 bug reports from 12 bug repositories. The bug reports are thoroughly examined to classify and extract information about the fault's cause (the error) and consequence (the failure and impact). Result: The majority (65%) of JavaScript faults are DOM-related, meaning they are caused by faulty interactions of the JavaScript code with the Document Object Model (DOM). Further, 80% of the highest impact JavaScript faults are DOM-related. Finally, most JavaScript faults originate from programmer mistakes committed in the JavaScript code itself, as opposed to other web application components such as the server-side or HTML code. Conclusion: Given the prevalence of DOM-related faults, JavaScript programmers need development tools that can help them reason about the DOM. Also, testers should prioritize detection of DOM-related faults as most high impact faults belong to this category. Finally, developers can use the error patterns we found to design more powerful static analysis tools for JavaScript.
Frolin S. Ocariza Jr., Kartik Bajaj, Karthik Pattabiraman, Ali Mesbah 0001
ESEM2