XFix: An Automated Tool for the Repair of Layout CrossBrowser Issues

Sonal MahajanUniversity of Southern California, USA

Abdulmajeed AlameerUniversity of Southern California, USA

Phil McMinnUniversity of She�eld, UK

William G. J. HalfondUniversity of Southern California, USA

ABSTRACTDi�erences in the rendering of a website across di�erent browserscan cause inconsistencies in its appearance and usability, resultingin Layout Cross Browser Issues (XBIs). Such XBIs can negativelyimpact the functionality of a website as well as users’ impressionsof its trustworthiness and reliability. Existing techniques can onlydetect XBIs, and therefore require developers to manually performthe labor intensive task of repair. In this demo paper we introduceour tool, XFix, that automatically repairs layout XBIs in web appli-cations. To the best of our knowledge, XFix is the �rst automatedtechnique for generating XBI repairs.

CCS CONCEPTS•So�ware and its engineering →So�ware testing and debug-ging; Search-based so�ware engineering;

KEYWORDSCross-browser issues; automated search-based repair; web apps.ACM Reference format:Sonal Mahajan, Abdulmajeed Alameer, Phil McMinn, and William G. J.Halfond. 2017. XFix: An Automated Tool for the Repair of Layout CrossBrowser Issues. In Proceedings of 26th ACM SIGSOFT International Sympo-sium on So�ware Testing and Analysis , Santa Barbara, CA, USA, July 2017(ISSTA’17-DEMOS), 4 pages.DOI: 10.1145/3092703.3098223

1 INTRODUCTIONCompanies invest a signi�cant amount of e�ort to design and imple-ment their websites. It is typical for companies to employ teams ofgraphic designers, web programmers, and testers to get a website’s“look and feel” correct across a plethora of browsers. �is e�ort isimportant because inconsistencies in the appearance or usabilityof a website when rendered in di�erent browsers, called LayoutCross Browser Issues (XBIs), can signi�cantly impact users’ overallevaluation of a website; particularly, impressions of trustworthinessand reliability. Layout XBIs are discrepancies in the arrangement ofHTML elements in a web page when rendered in di�erent browsers,and can occur frequently due to di�erences in the implementationof HTML and CSS standards in di�erent browsers’ layout engines.Layout XBIs are by far the most prevalent type of XBIs, observedin over 56% of the websites [10].

In general, debugging and repairing XBIs is challenging and hasbeen a serious concern for web developers for a long time. For

ISSTA’17-DEMOS, Santa Barbara, CA, USA2017. 978-1-4503-5076-1/17/07. . .$15.00DOI: 10.1145/3092703.3098223

example, over 23,000 posts are reported for the search term “crossbrowser” on StackOver�ow [12]. First, the sheer number of HTMLelements and CSS properties that could be faulty, coupled withtheir complex interaction, makes it a di�cult and labor intensivetask. Second, repairing the XBIs by identifying correct �x valuesfor CSS properties without introducing new XBIs is complex giventhe strong dependency between HTML and CSS, and their e�ecton a page’s layout. �ird, developers need to repeat this task forevery browser showing an inconsistency. XBI testing tools such asX-PERT [10] can only detect and identify faulty HTML elements;�nding faulty CSS properties and �x values for a repair is still amanual e�ort.

To address these limitations, we proposed a novel automatedtechnique [4] to repair layout XBIs in web applications. It usessearch-based techniques to identify repair solutions. Our key in-sight is that the amount of layout deviation given by the positionand size of HTML elements of a web page rendered in di�erentbrowsers can be used as a �tness function to guide the explorationto likely solutions. When the amount of layout deviation convergesto zero, the layout of a web page renders consistently in two di�er-ent browsers, and a fault has likely been identi�ed and repaired. Inour evaluation, our technique was able to repair 86% of the XBIsdetected by X-PERT and 99% of the XBIs observed by humans.

In this demo paper, we describe the implementation details ofour repair technique [4]. We implemented our technique in a toolcalled XFix (available at h�ps://github.com/sonalmahajan/x�x). Touse XFix, users need to only provide a page under test and twobrowsers showing layout deviations (i.e., XBIs). XFix processesthese inputs and modi�es the page under test with a CSS repairpatch that �xes the layout XBIs.

2 ENVISIONED USERS AND SCENARIOSWe envision the users of XFix as developers, testers, and supportengineers of web applications seeking repair solutions for layoutXBIs1. In this section, we discuss three usage scenarios in whichXFix can assist its users in �xing XBIs automatically.

Repair Web Pages in Development. While implementing awebsite, web developers typically test it frequently on their “fa-vorite” (reference) browser to ensure that it functions and renderscorrectly. A�er testing successfully on the reference browser, de-velopers then typically test for XBIs by checking the website’srendering compliance with other browsers. If XBIs are detected,developers spend time and e�ort in debugging and repairing thepage. �is manual e�ort can be saved by using XFix.

1Herea�er, we refer to layout XBIs as simply XBIs.

ISSTA’17-DEMOS, July 2017, Santa Barbara, CA, USA Sonal Mahajan, Abdulmajeed Alameer, Phil McMinn, and William G. J. Halfond

Pageundertest

(PUT)

Referencebrowser

Testbrowser

X-PERT User

<l1,e1,e2>

<l2,e1,e2>

<ln,e1,e2>

.

.

<e,p,v,v’>

Repairedpage

(PUT’)

✔

✗

Inputs XFixtool Output

LayoutXBIs Rootcauses3.Searchfor

candidatefixes

4.Searchforbestcombina6on

ofcandidatefixesCandidatefixes

<e1,p1,v1,>..

<e2,pn,v1n>

<e1,p1,v1,>..

<e2,pn,v1n>

<e1,p1,v1,>..

<e2,pn,v1n>

<e,p,v,v’><e,p,v,v’>

1.Ini6alXBIdetec6on

CSS-labelmap

2.Extractrootcauses

5.CheckTermina6on

criteria

Y

N

repair.css

<e1,p1,v1>

<en,pn,vn>

.

. <e,p,v,v’>

Figure 1: High-level overview of XFix tool

Repair Web Pages in Testing. A�er a web app has been im-plemented, it is typically sent to testing teams for veri�cation andvalidation. Testers usually check for XBIs during User Interface (UI)testing, and if an XBI is detected, �le a bug report and assign it to adeveloper for �xing. �e developer then manually �xes the bug andreassigns it to testers for validation. �is is a fairly time consumingprocess that is potentially further complicated if the developmentand testing teams are not in the same geographic location. XFixcan assist testers in this scenario by automatically repairing thedetected XBIs, completely avoiding the loop of assigning a bug to adeveloper and re-validating the �x.

Repair Web Pages in Maintenance. Owners of legacy webapplications (i.e., web applications in the maintenance phase of theso�ware lifecycle) may want to maintain consistency of their webapplications across newly launched browsers or newer versionsof existing browsers. Production support engineers maintaininglegacy projects are generally di�erent to the original set of develop-ers and testers, and may not have the required HTML expertise torepair XBIs. It may also be expensive to hire new developers solelyfor the purpose of �xing XBIs. In this case, XFix can e�ectivelyassist the production support engineers in repairing XBIs observedin existing web pages. �e engineer can validate the repair and ifsatis�ed, deploy the �xed page in production.

3 TOOL DESCRIPTION AND USAGE�e goal ofXFix is to repair XBIs detected in a web page by �ndingpotential �xes for them. XFix is implemented in Java and is astandalone tool that exposes a simple API to specify inputs andrun the repair technique. To facilitate easy management of third-party dependencies, XFix is packaged as a Maven project. XFixcan be run on any platform, such as Windows, Linux, and macOS.Since XFix analyzes the client side code of the page under test, itis agnostic to the server side technology used.

Figure 1 shows a high-level overview of XFix. A user of XFixis required to provide three inputs, a page under test (PUT), a

(a) Correct rendering of the page with Internet Explorer 11.0.33

(b) Displaying an XBI when rendered with Mozilla Firefox 46.0.1

Figure 2: Excerpts of the navigation bar on the IncredibleIndia homepage,which has an XBI making the text unreadable in Firefox.

reference browser (R), and a test browser (T ). Users of XFix toprovided R and T is a reasonable assumption in this domain, asthey typically know the expected appearance of the PUT. For thePUT, the user needs to provide a URL pointing to the location ofthe HTML page on the �le system where all the CSS, Javascript,and media necessary for rendering the PUT can be accessed. Forproviding R andT ,XFix provides an option to select a browser fromXFix’s supported set of browsers. XFix currently supports all theversions of the three most widely used browsers, Firefox, Chrome,and Internet Explorer (IE). More browsers can be easily added toXFix by including the browser’s standalone server implementationof the SeleniumWebDriver’s wire protocol. Note that R andT needto be pre-installed on the user’s computer.

We now summarize the di�erent stages of XFix’s technique inthe following subsections along with their implementation details.Further algorithmic details of the technique are available in ourISSTA’17 paper [4]. Figure 1 shows the di�erent stages of XFixin italics. Figure 2 is used as a running example to explain thedi�erent stages. �e example shows screenshots of the menu barof one of our evaluation subjects, IncredibleIndia, as rendered inIE (Figure 2a) and Firefox (Figure 2b). As can be seen, an XBI ispresent in the menu bar, where the text of the navigational linksis unreadable in the Firefox browser (Figure 2b). �is particularexample was chosen because the repair is simple and easy to explain.However, most XBIs are much more di�cult to resolve, with therepairs o�en spanning over multiple elements and CSS properties.

<TOP-ALIGNMENT,</HTML/BODY/DIV[3]/DIV/DIV,/HTML/BODY/DIV[3]/DIV)>>

label e1 e2

Figure 3: Layout XBI report from X-PERT with its constituent parts labelled

Stage 1: Initial XBI Detection. In this stage, XFix identi�esthe set of XBIs observed in the PUT rendered in T with respect toR. XFix uses Selenium WebDriver to open R and T and render thePUT in them, and then capture Document Object Model (DOM)information including XPath, location, and size of the elements.XFix then invokes X-PERT [10] by passing the two DOMs as inputto obtain a set, X , of detected XBIs. X-PERT reports each XBI asthe tuple 〈label, 〈e1, e2〉〉, where 〈e1, e2〉 is a pair of HTML elementsin the PUT that is inconsistent in layout in T with respect to R,and label describes the layout problem. As shown in Figure 3 forthe running example of Figure 2, label TOP-ALIGNMENT indicatesthat element e1 is positioned on the top edge of element e2 in R,but not in T . Another example of a label reported by X-PERT isLEFT-RIGHT that indicates that e1 is on the le� of e2 in R, but not

XFix: An Automated Tool for the Repair of Layout Cross Browser Issues ISSTA’17-DEMOS, July 2017, Santa Barbara, CA, USA

e1

n1

(10,0)

(10,100)

(a) Location of e1 and its neighbor, n1, in R

(10,-20)

(10,80)

(b) Location of e1 and n1 in T . Fitness score = 60.

(10,-5)

(10,95)

(c) Evaluating margin-top = 15px, Fitness score = 15.

Figure 4: Fitness score computation in stage 3 — lower �tness score indicates a better candidate �x (i.e., �tness is to be minimized)

in T . Note that we used the publicly available version of X-PERT(h�ps://github.com/gatech/xpert) by making minor changes to �xbugs and add accessor methods for data structures. Due to spacereasons, we describe the details of our changes to X-PERT on theXFix project page (h�ps://github.com/sonalmahajan/x�x).

Stage 2: Extract Root Causes. In this stage, XFix extracts theroot causes for each XBI detected in stage 1. A root cause is de�nedby the tuple 〈e,p,v〉, where e is an HTML element in the PUT, p isa CSS property of e , andv is the value of p. For each XBI, XFix �rstidenti�es a set of CSS properties relevant to the label descriptor.For doing this, we created a CSS-label map. For example, for theTOP-ALIGNMENT label, the CSS properties margin-top and topare relevant since they can alter the top alignment of an elementwith respect to one another. Note that this CSS-label map is aninherent part of XFix and does not require any further manualinput from the user. �en for each CSS property, p, in the identi�edset, XFix adds two root causes, one for e1 and one for e2 (Figure 5).

Stage 3: Search for Candidate Fixes. In this stage, XFix per-forms a guided search over each of the root cause tuples populatedin stage 2 to �nd individual candidate �xes. To do this, we imple-mented a search to be used in a single variable mode inspired by thevariable search component of theAlternating VariableMethod (AVM)technique [2]. �e AVM is a local search strategy that �rst estab-lishes a direction for the search, and then rapidly explores the spacein that direction to �nd the optimal solution. We use the AVM tech-nique as it accelerates the hill climbing search, thus helping achievea quick convergence. XFix uses the AVM in a single variable modeby rese�ing the PUT to its original form before running the searchon a root cause tuple to �nd a potential �x value, v ′. For each rootcause processed, XFix reports a candidate �x tuple 〈e,p,v,v ′〉.XFix applies each v ′ to the PUT rendered in T by using Sele-

nium WebDriver to execute a Javascript function that dynamicallymodi�es the DOM of a web page. XFix then extracts the updatedDOM to compute the �tness score. �e �tness function analyzesthe relative layout deviation of e in the PUT when rendered in Rand T with respect to its local neighborhood. For quantifying thelayout deviation, XFix considers three components: (1) di�erencein the location of e , (2) di�erence in the size of e , and (3) di�erencesin the location of e’s neighbors. �e �tness score is calculated as aweighted sum of the three components. �e �tness function has aminimizing goal, i.e., a lower �tness score indicates a be�er candi-date �x. We set the radius as 2 for de�ning the local neighborhood,and weights as 1, 2, and 0.5 for the three components, respectively.

1.</HTML/BODY/DIV[3]/DIV/DIV,margin-top,-20px> 2.</HTML/BODY/DIV[3]/DIV/DIV,top,0px>3.</HTML/BODY/DIV[3]/DIV,margin-top,0px>4.</HTML/BODY/DIV[3]/DIV,top,0px>

Figure 5: Extracted set of root causes for the XBI in Figure 3

Continuing with the running example, consider the processingof the root cause tuple 〈e1, margin-top,−20px〉. e1 is located at(10, 0) and its neighbor, n1, at (10, 100) in R (Figure 4a). In T , e1 islocated at (10, -20) and n1 at (10, 80), leading to a �tness score of60 (Figure 4b). Trying v ′ = 15px moves e1 to (10, -5) and n1 to (10,95), resulting in a �tness score of 15 — indicating that the search isprogressing in the correct direction (Figure 4c).

Stage 4: Search for Best Combination of Candidate Fixes.In this stage, XFix seeks to �nd a repair set for the PUT by �ndingan optimal combination of candidate �xes identi�ed in stage 3. �isadditional search is necessary since not all candidate �xes may berequired, as the identi�ed individual �xes may have duplicating,multiplying, or competing e�ects. For example, candidate �x tuples,〈e1, margin-top, 0px , 20px〉 and 〈e1, top, 0px , 20px〉 in our runningexample both result in a �tness score of 0 (perfect repair), howeverwhen applied together result in a multiplying e�ect introducinganother XBI. For this stage, XFix uses a directed random search toidentify the best combination. XFix selects a candidate �x witha probability imp�x/impmax . Here imp�x is the improvement ob-served in the �tness score when the �x was evaluated in stage 3 andimpmax is the maximum improvement observed over all candidate�xes. XFix then dynamically applies each v ′ in the selected �x tu-ples to the PUT, and uses the number of XBIs reported by X-PERTas the �tness score. XFix adds the �x tuples resulting in the lowest�tness score to the repair set. �e search terminates when (1) thenumber of XBIs in the PUT equals zero, (2) the allo�ed resources(maximum number of �tness evaluations = 50) are exhausted, or (3)a saturation point is reached — i.e.,m = 10 consecutive tries resultin no �tness score improvement.

Stage 5: Check Termination Criteria. �is stage determineswhether XFix should terminate or continue searching for morerepair alternatives. For this, XFix �rst applies the identi�ed repairto the PUT to create the modi�ed page PUT′, and runs X-PERT onPUT′ to identify new set of XBIs, X ′. XFix terminates if the PUTis completely repaired, X ′ shows no improvement compared to theprevious iteration, or X ′ reports more XBIs, making the currentrepair unviable. If none of the termination conditions are satis�ed,X ′ is assigned as the current set of XBIs,X , and PUT′ as the currentPUT, and XFix loops back to stage 2 for the next iteration.

Upon termination, XFix generates a repair.css �le (shown inFigure 6 for the running example) containing the repair patch andmodi�es the PUT �le to include repair.css in the 〈head〉 sectionof the HTML of the page. Note that a new repair.css is createdwith a timestamp appended to the name for every run of XFixto e�ectively resolve XBIs across di�erent test browsers for thePUT. XFix generates the repair.css as follows. First, XFix addsa browser speci�c quali�er corresponding to the test browser (e.g.,-moz for Firefox) as shown in line 1 of Figure 6. Such quali�ers

ISSTA’17-DEMOS, July 2017, Santa Barbara, CA, USA Sonal Mahajan, Abdulmajeed Alameer, Phil McMinn, and William G. J. Halfond

direct the layout engine to use the provided alternate values forthe CSS property when it is rendered on a speci�c browser. Forexample, the repair patch shown in Figure 6 is only applied if thebrowser type is Firefox, and is ignored by the layout engines ofother browsers. Developers widely employ this approach to repairXBIs. In our analysis [4] of the top 480 websites, 79% containedthis type of browser-speci�c CSS code. �en, for each �x tuple〈e,p,v,v ′〉 in the repair set identi�ed in stage 4, XFix convertsthe XPath of the element e to a CSS selector and adds it to thebrowser speci�c quali�er block. For example, line 2 shows the CSSselector derived from the XPath, /html/body/div[3]/div/div.XFix then converts the �x value v ′, which is an absolute value(e.g., margin-top:20px), to a relative �x value with respect to anelement’s parent’s dimensions, such as margin-top:1.7%. XFixthen adds this relative �x value for the CSS property p (line 3).

1.@-moz-documenturl-prefix(){2. html>body>div:nth-of-type(3)>div:nth-of-type(1)>div:nth-of-type(1){3. margin-top:1.7%!important;/*20px*/4. }5.}

Figure 6: repair.css generated for IncredibleIndia example of Figure 2

4 EVALUATIONIn this section we summarize the results of our empirical evaluationobtained by running XFix on 15 real-world web pages [4].XFix was able to resolve an average of 86% (median 93%) XBIs

reported by X-PERT, and an average of 99% (median 100%) humanobservable XBIs. XFix required a median running time of 14 min-utes. XFix, on average, generates a repair patch of 9 CSS properties.�is number is comparable to the browser-speci�c code size foundin our analysis of 480 Alexa websites.

We also conducted a human study to measure the impact ofXFixon the cross-browser consistency of the page. Based on user ratingswe found that 78% reported an improved consistency of the pagea�er the �x. �is implies that XFix generated �xes that improvedthe consistency of the subjects across the di�erent browsers.

5 RELATEDWORKMany search based techniques have been proposed in the �eld ofso�ware program repair that focus on Java and C programs [3,15]. To our knowledge, XFix is the �rst technique that can repairpresentation problems, such as XBIs, in web applications. Anothertechnique [14] uses static and dynamic analysis to propagate agiven client-side �x to the server-side source code. However, thistechnique cannot �nd the �x automatically.

Cross Browser Testing (XBT) techniques, such as X-PERT [10]and Browserbite [11], can be used to detect and localize XBIs. How-ever, �xing the reported XBIs is still a manual e�ort.

Work in the �eld of web app presentation testing, such as Web-See [5–7] and FieryEye [8, 9] focuses on detecting and localizingpresentation failures — a discrepancy in the actual and intendedappearance of a web page . Another technique, GWALI [1], can de-tect layout failures in web pages a�er they are translated from onelanguage to another. �e ReDeCheck technique [13], uses a layoutgraph to detect potential layout faults in responsive web pages.�ese techniques are useful in detecting and localizing UI failures.However, �xing the detected failures is still a manual process.

6 CONCLUSION AND FUTUREWORKIn this paper, we presented XFix, a fully automated tool for re-pairing layout XBIs in web applications. XFix uses a two-phasedguided search approach to minimize the layout deviations observedin a page rendered in di�erent browsers. �e strong results of ourevaluation indicate that XFix can be a useful and highly e�ectivetool for automatically repairing layout XBIs in web pages.

In future work, we plan to extendXFix to support repair of cross-platform XBIs, such as across desktop and mobile environments.We also plan to produce repair patches for the CSS dynamically gen-erated from other sources, such as Sass and server-side Javascript.Another direction we plan to work on is to automate the process of�nding reference and test browsers from the set of XFix supportedbrowsers. �is can be possibly done by analyzing the XBIs reportedby X-PERT for pairwise combinations of the browsers.

ACKNOWLEDGMENTS�is work was supported by NSF grant CCF-1528163.

REFERENCES[1] Abdulmajeed Alameer, Sonal Mahajan, andWilliam G.J. Halfond. 2016. Detecting

and Localizing Internationalization Presentation Failures in Web Applications. InProceeding of the 9th IEEE International Conference on So�ware Testing, Veri�cation,and Validation (ICST).

[2] Joseph Kempka, Phil McMinn, and Dirk Sudholt. 2015. Design and Analysis ofDi�erent Alternating Variable Searches for Search-Based So�ware Testing. In�eor. Comput. Sci., Vol. 605. 1–20.

[3] Fan Long and Martin Rinard. 2015. Staged Program Repair with ConditionSynthesis. In Proceedings of the 10th Joint Meeting on Foundations of So�wareEngineering (ESEC/FSE).

[4] Sonal Mahajan, Abdulmajeed Alameer, Phil McMinn, and William G.J. Halfond.2017. Automated Repair of Layout Cross Browser Issues Using Search-BasedTechniques. In Proceedings of the 26th International Symposium on So�ware Testingand Analysis (ISSTA).

[5] Sonal Mahajan andWilliam G. J. Halfond. 2014. Finding HTML Presentation Fail-ures Using Image Comparison Techniques. In Proceedings of the 29th IEEE/ACMInternational Conference on Automated So�ware Engineering (ASE) – New Ideas.

[6] Sonal Mahajan and William G. J. Halfond. 2015. Detection and Localization ofHTML Presentation Failures Using Computer Vision-Based Techniques. In Pro-ceedings of the 8th IEEE International Conference on So�ware Testing, Veri�cationand Validation (ICST).

[7] Sonal Mahajan and William G. J. Halfond. 2015. WebSee: A Tool for Debug-ging HTML Presentation Failures. In Proceedings of the 8th IEEE InternationalConference on So�ware Testing, Veri�cation and Validation (ICST) – Tool track.

[8] Sonal Mahajan, Bailan Li, Pooyan Behnamghader, and William G. J. Halfond.2016. Using Visual Symptoms for Debugging Presentation Failures in WebApplications. In Proceedings of the 9th IEEE International Conference on So�wareTesting, Veri�cation and Validation (ICST).

[9] Sonal Mahajan, Bailan Li, and William G. J. Halfond. 2014. Root Cause Analysisfor HTML Presentation Failures Using Search-based Techniques. In Proceedingsof the 7th International Workshop on Search-Based So�ware Testing (SBST).

[10] Shauvik Roy Choudhary, Mukul R. Prasad, and Alessandro Orso. 2013. X-PERT:Accurate Identi�cation of Cross-browser Issues in Web Applications. In Proceed-ings of the International Conference on So�ware Engineering (ICSE).

[11] Nataliia Semenenko, Marlon Dumas, and Tnis Saar. 2013. Browserbite: AccurateCross-Browser Testing via Machine Learning over Image Features. In Proceedingsof the IEEE International Conference on So�ware Maintenance (ICSM).

[12] Stackover�ow. 2017. Stackover�ow Cross-browser Posts. Retrieved Jan 2017from h�p://stackover�ow.com/questions/tagged/cross-browser

[13] �omas A. Walsh, Phil McMinn, and Gregory M. Kap�ammer. 2015. AutomaticDetection of Potential Layout Faults Following Changes to Responsive WebPages. In International Conference on Automated So�ware Engineering (ASE).

[14] Xiaoyin Wang, Lu Zhang, Tao Xie, Yingfei Xiong, and Hong Mei. 2012. Au-tomating Presentation Changes in Dynamic Web Applications via CollaborativeHybrid Analysis. In Proceedings of the ACM SIGSOFT 20th International Sympo-sium on the Foundations of So�ware Engineering (FSE).

[15] Westley Weimer, �anhVu Nguyen, Claire Le Goues, and Stephanie Forrest. 2009.Automatically Finding Patches Using Genetic Programming. In Proceedings ofthe 31st International Conference on So�ware Engineering (ICSE).