Browser options for adaptive system

Adaptive Browser Rendering

1. Must have a self-contained HTML renderer and JavaScript interpreter so that basic code manipulation can be applied (such as running JS scripts to test if certain features are avail- able).

2. Reliability and stability of technology to ensure that the foundation of the system is adequate for real use and not a critical point of failure.

3. Ease of use for automation and development.

4. Active support and community, to ensure the project is kept up-to-date, with the rapid evo- lution of the Web and to rapidly fix any bugs that may emerge in this environment.

Initially for this work, the following were looked at: Selenium [29] which is the name for a suite of applications designed for web browser automation. PhantomJS [23] a headless WebKit- based tool. SlimerJS a scriptable browser based on Firefox’s rendering engine Gecko [6]. Though the latter is not headless by default it can run with UI in Linux and Mac OSX. Lastly Awesomium an HTML UI Engine written in C++/.Net will also be considered.

In the following sections, we shall talk about our findings of these four options based on the criteria given.

4.2.1.1 HTML renderer and JavaScript interpreter

While this criterion might at first appear strange to the reader, during research it became apparent that whilst the presence of an embedded HTML renderer and JavaScript interpreter are inherently available to any browser, the same does not happen in "browser-like" options. Our objective is to create an adaptive browser, and in order to do so we must be able to manipulate its output after the initial web page processing has concluded. This is so we can validate its output by executing specific tests. For instance, with the HTML5 specification certain features were added, like new dynamic HTML elements and support for different audio encodings. The methodology used to test support for these features came in the form of JavaScript files. The idea surged from a popular JavaScript library Modernizr [5], which is essentially a series of JavaScript tests intended to verify if certain features are available in any given browser. This code works through "shims", which are backwards-compatible pieces of code that work across multiple browsers, the tests used can be seen here [2].

In this criteria, the library Awesomium was rejected because of the C++ bindings needed to manipulate JavaScript code, which in turn is required to retrieve information about the rendered page (see figure4.2).

Adaptive Browser Rendering

Because Awesomium uses WebKit as the underlying HTML rendering engine, no extra infor- mation could be extracted from its use that couldn’t be done with PhantomJS (which also uses WebKit) or Chrome via Selenium (for this component in the system). Ergo it was decided that the extra work needed to add Awesomium to the testing framework was not worthwhile.

Figure 4.2: Awesomium JS binding for global objects [7]

4.2.1.2 Performance, Usability, Reliability and Stability

Having a stable environment is critical to the system we are attempting to build. Simply because of the sheer number of potential points-of-failure. If the base case does not perform as expected it can

Adaptive Browser Rendering

invalidate the work done by the other components of the system, and output incorrect information without having any mechanism able to correct it.

In this case, SlimerJS did not function as expected. The current API available to work with is inadequate for intensive usage, as no garbage collection can be explicitly done. Making executing a tool with this library for multiple files/URLs overload the system’s resources. Requests to change this have been filed, but due to a lack of contributions and development of this library, it is unlikely that such change will occur during the time of this thesis. Another reason that lead to dropping SlimerJS was the lack of benefits performance-wise, for a headless solution. Running this library will create a window in which to render the requested page. The advantage of this according to the developer, was that any update to the firefox browser will be present in SlimerJS, allowing for security and performance upgrades to come, however for the current scenario, it makes it no different than using selenium with Firefox.

During development of the testing framework and subsequent execution of the tests, both PhantomJS and Selenium functioned as intended, in that their APIs were very similar and allowed almost the same code to be used. They were also reliable and easily manipulated. Further testing was done in regards to reliability and performance, for more information please see the Results chapter.

4.2.1.3 Support and community

In terms of active support and community, both Selenium and PhantomJS options provide inter- esting scenarios. Because Selenium is a wrapper to actual full featured browsers, support for new technologies bug fixes are done by the developers of this software, namely Mozilla, Apple, Mi- crosoft and Google to name a few. An update to the browser installed on the system would imply that the adaptive system on which it relies would also automatically update with little extra work. PhantomJS on the other hand, to become up-to-date with newer features, takes more time and in some cases, the developers decide not to implement them at all (see [24]).

4.2.1.4 Additional observations

After the experiences mentioned above with simple testing and usage, we were left with Phan- tomJS and Selenium. For Selenium we chose to test two browsers Google Chrome and Firefox, the reason being that they are the two most used browsers at the time of writing this thesis, and also very importantly, is that both options work across operating systems.

Adaptive Browser Rendering

To note that, here neither Internet Explorer nor Safari are included in the Selenium option. This is because both browsers and corresponding webdrivers [3], require a Windows and Mac OS operating system respectively, making it inadequate for server deployment on Linux systems. Furthermore, Internet Explorer does not allow the possibility of opening local files through the file:// schema used (see Results chapter) to process our test suite. This, however, does not exclude either browser from being used to "show" the system it’s differences, merely from using them as the "base" browser.

Adaptive Browser Rendering