A Simple framework for extending BOM/DOM APIs

on Chromium based browser for Android OS

Amit Singhai, Praveen Kumar, Priyesh Laker, Aditi Bansal

Web Solutions Group
Samsung R&D Institute India, Bangalore (SRI-B)
{a.singhai, prav.k, pri.lakar, aditi.bansal}@samsung.com

Abstract— In this paper we propose a simple solution for the location, history, frames and any other functionality the
problem of providing additional functionality for web content browser may expose to JavaScript.
apart from what a typical web browser provides by default.
There are multiple solutions such as browser plugins which are
installed separately and have their own lifecycle. Some browsers
provide custom java script objects to access additional
functionality by embedding precompiled JavaScript and native
code. In this research we find out an application layer approach
to add and expose additional functionality into a chromium
engine based browser. The functionality is exposed as very
generic extension to BOM/DOM APIs, so that the content
developers do not have to deal with customized object names
which vary from browser vendor to vendor. This BOM/DOM
extension also helps the browser vendors in reducing dependence
on out of the box plugin installations at the same time make
content development easy with typical JavaScript or other UI
libraries. As part of same research we find out typical execution
Figure 1- A Typical Document Object Model of a web page
time for executing various API calls, which can help architects
and designers in designing such a system with optimal
performance needed for their respective web applications.
The Browser Object Model is not standardized and can
change based on different browsers. The browsers are split into
Keywords—Browser object model; web browser; Document different objects that can be accessed using our very own
object model, java script, chromium, android, Content View JavaScript. These parts are collectively known as BOM. At the
very top of this browser hierarchy is the Window object. It
I. INTRODUCTION represents the entire browser, with its toolbars, menus, status
A typical web browser provides all necessary facilities for a bar, the page itself, and a whole lot more besides. Effectively,
web page to render on screen and interact with user the Window is the browser only. Underneath the Window
dynamically. A web page is consists of HTML [1], JavaScript Object, there are lots of other objects which can be accessed by
[2] and CSS [3]. When an HTML is received by the browser it us. These allow us to do things like, redirecting the user to a
prepares a document object model of the page, and the page is different web page, get the size of the browser window, and
associated with browser’s own features in a hieratical structure access all the HTML elements on the page and, again, a whole
called browser object model. lot more besides all these features. One can simply change the
color of a toolbar or may run an application just by using the
The Document Object Model, popularly known as DOM plug-ins which will be made enabled on the browser view.
[4] is an application programming interface for all HTML and Figure-2 shows a typical BOM of a web browser
XML documents. It is a standardized model and is a core part
of our web browser. It is all about the logical structure of our
documents and the way in which we can access and manipulate
them. With the help of Document Object Model, developers
can build web documents, navigate their structure and more
over modify, add or delete elements and contents. In Web
browser the Document Object Model (DOM) and JavaScript
are tightly bound. Each major browser line has its own
overlapping DOM implementation. Fig-1 shows a typical html
document structure of a web page. The Browser Object Model Figure 2- Browser Object Model of a typical web browser
(BOM)[5] allows JavaScript to "talk to" the browser. The
Browser Object Model is a larger representation of everything One more important topic we would like to mention is Web
provided by the browser including the current document, browser engine which is basically core of any web browser. It
consists of JavaScript core and interacts with underneath APIs need to offer and that too for accessed by browser
platform APIs which are mainly written in C/C++. Browser plugins. With this approach custom handling has to be done in
engine also interacts with rendering engine to present finally page source code which is browser specific. To perform a
rendered page on the device screen. The java script APIs single change entire browser code has to be compiled.
provided by default are mainly wrappers over native APIs of However this approach provides good encapsulation of various
the browser engine. use cases in one Java Script Object. For Android OS this
approach is particularly complicated because of porting
Content developers always need customization of the perspectives of both programming language and platform
browser environment to adopt various requirements such as capabilities and limitations. For Android OS easy integration
new sensor integration, web based application development with Android Java is very much needed.
platforms. Even now a day there has been as great progress in
web based Operating Systems such as Chrome OS, Firefox OS WRT (Web Run Time) [11] also offers many extensions
and latest Tizen OS. All these platforms provide extensive web and APIs in comparison to plain browser engine. In WRT the
APIs for web applications which are usually provided by native extension are provided for specialized web applications such as
code in non-web based platforms. There have been several device APIs, file system APIs etc. This case is similar to
enterprises which have extended web capabilities and provided custom objects explained above. Our framework is different in
then in form of JavaScript APIs. In this work we try to use terms of no independent objects are provided rather existing
various JavaScript APIs coupled with our BOM/DOM standard methods and objects are used to provide additional
structure so as to make new browser features available to web APIs without changing native complicated code. Our
pages. framework implementation is entirely on top application layer
whereas existing approaches are tide up to native lower layers.
The rest of the paper is organized as follows: Section 2
looks at related work. Section 3 discusses proposal and III. FRAMEWORK PROPOSAL AND IMPLEMENTATION
implementation of our framework. In section 4 we perform
various experiments to find out performance of the framework, In this section we use a chromium based browser on
this helps in designing the APIs. Section 5 section concludes Android operating system and implement our framework on it.
the paper. Android SDK provides a web view which can be embedded
into any application or it is possible to use content view and
II. RELATED WORK AND PROBLEM STATEMENT chromium open source to create a simple browser. The
chromium engine is used by my mobile browsers such as
Our research in this paper is about how to provide Opera, Chrome etc. Since our framework is completely on
extended functionality over the default one provided by the Android application side it can be easily integrated in any
browser. In this section we explore various existing chromium [12] based browser or a Web View [13] based
methods and systems available to extend browser features browser.
and how our framework is different than the existing
implementations.
A. Plugins and NPAPI
One of the oldest methods of extending browser
functionality is via NPAPI [6]. It allows a user to install
additional components which are mainly native shared
libraries. These additional binaries are detected by browser
using system registry or predefined folder of installation.
Other plugin methods are also available such as Mozilla
XPCOM [7], Microsoft COM [8]. For Android OS extensions
are possible using AIDL [9]. Problem with this approach is
user has to install the plugins needed and the web page code
must be put in place to initiate and interact with the plugin. The
interface depends on the plugin and the browser vendor too.
With our framework there is no such need as extended APIs
are provided in form of BOM/DOM objects which are readily
available.
B. Custom Java Script objects and WRT Figure 3- Chromium Content View
Some browsers such as Google’s Chrome or Mozilla Content View is an empty frame layout [14] to play a
Firefox for desktop devices provide custom Java Script objects mediator role between Android view system and native
to provide additional functionality to web pages. Let’s take one browser engine. Few such responsibilities are delegating
example to understand this approach. Google’s Chrome Android touch events to native engine and delegating native
browser implements a readily available Object called chrome calls to Android code such as page load complete, page load
[10] with Java Script API. A web page’s Java Script can use started etc.
this object to access browser UI, Content, Settings even many
platform APIs. This approach is very good when a lot of native
 Content view provide way to inject a java script function via We now look into various API declarations which are
“evalulateJavaScript()” API into web content. Android side easily possible with proposed framework. We can actually
Java objects can also be injected into html page as JavaScript categorize the APIs based on browser features available.
Objects. This Java object injection is the most important
feature of content view for our framework. We use this Table-I shows some of the APIs we implemented as part of
functionality to inject API Wrapper class’s instance into web the framework however framework is not only limited to these
content. Now web content’s side all the methods of the APIs but can be extended.
wrapper class are visible as JavaScript function calls. The API TABLE I. BOM API EXTENSIONS AND ADDITIONS
wrapper class internally co-ordinate with all browser feature
classes that we want to expose as DOM/BOM extension. Object API addition Sub APIs and remarks
modified
For example: JavaScript “window.document” object can be
window window.toolbar toolbar.matchPageBGColor()
extended to support one more function to trigger page saving
on local storage like below snippet. toolbar.insertAction()
toolbar.enableHide()
These APIs manipulate browser toolbar.
window.screen Screen.applyTransform()

To implement the complete framework we first implement

the Android Java glue code. The Glue code is basically facade TABLE II. DOM API EXTENSIONS AND ADDITIONS
classes and interfaces for existing Java classes of browser
application. These glue classes are finally wrapped in Object API addition Remarks
modified
APIWrapper class mentioned previously in the section. On
start of application all the glue code is instantiated and Document document.share(String s) Android intent may be
APIWrapper is registered as JavaScript object with content fired to use platform
document.save(void) capabilities such as
view. It would make the object available in when html page showing available sharing
load finishes. applications.
document.showToWearable(ele Any child of DOM can
ment) passed as parameter

We introduced new methods and objects into existing BOM

and DOM API Objects which content can easily utilize without
worrying about custom object names. One such use case is
page want to adopt the browser’s toolbar color to its page
background color, it can do so by calling
toolbar.matchPageGBColor(), on the window object itself. The
call is propagated from JavaScript to glue code and thus finally
to Toolbar classes of Android application. Similarly other API
methods are self-explanatory for intended functionality. Next
section compares proposed framework with some existing
approaches and finds out various pros and cons.
IV. FRAMEWORK INTEGRATION AND RESULTS
Implemented framework has mainly Android Java files and
supplementary JavaScript files. The JavaScript files can be
added to the html pages by the content providers or websites
Figure 4- Framework Architecture
however this is optional as browser contains all extension
As part of framework we also developed supplementary objects already on page load completion. The most important
JavaScript which is injected in page via evaluateScript() API to part of this framework is APIWrapper Java classes. These
make the BOM/DOM objects extended and readily available classes internally call all the remaining application as well as
for a page when it finishes loading. The same java script can Android platform APIs. The concrete implementation of the
also be part of web content if deployed on web server as an glue code in these classes is out of scope so we demonstrate
alternative approach to make the extension API available only only how to make one such wrapper class functionality
to partner websites instead of generally to all. The scope for available for JavaScript at run time. Considering we want to
such kind of implementation is out of scope of this paper. extend JavaScript “window” object and provide a child object
called “toolbar” to so that content can access our browsers
toolbar methods. To do so simple integration steps are as
follows:-
 1. Create class APIWrapperToolBar
2. Annotate all extension methods as
@JavascriptInterface
3. Instantiate APIWrapperToolBar on application’s
Main Activity creation
4. Find out page load finish event callback, ref Figure-5
5. Register APIWrapperToolBar instance, with Content
View on the callback using
addJavaScriptInterface[15]
A code level example of availing toolbar object inside
content via javascript may be given as following snippet and
similarly all such APIWrappers can be integrated with the
content.

Figure 5 Event flow for JSAPI object insertion

To demonstrate functionality on real webpage the
framework provides BOM and DOM APIs for real world
requirements such as sharing a web page, saving page to local
disk, allowing content to show HTML element so that use can
add the current loaded URL In bookmarks. Figure-6 shows all
above mentioned implementations.
Results:
 On touching “Share Me” button on page , Android’s
Share activity launches directly.
 On touching “Add me as bookmark” button the URL
is added into bookmark folders
 On touching “Save me” the page is stored on
persistence store for offline reading.
The architects and designers of the extension framework
should consider the performance of exposed APIs before
exposing them to the content providers. This is one of the most
important considerations as it affects the usability of the
framework APIs. As we have stated earlier it is an application
side framework, designed for simplicity and easy adoption.
When API is consumed by content in JavaScript the calls are
delegated to Java code and vice versa. We performed an
experiment to determine approximate time taken to call Java
Script to Java functionality for various sizes of input
parameters. Let’s take example of document.share(String url)
API. This API takes current URL as input and transfer to social
application selected by user on clicking “Share me” button.
Size of URL may vary from few bytes to approximately 2KB. Figure 6 Results of framework integration
Considering a developer decide to provide the share API for an
Image present in content. Image size may vary from few KB to The framework may provide user consent popup dialog to
few MBs. As par figure-7 it may take very long time for the proceed for API execution for some critical APIs, such as
API execution which leaves it un-usable, in such case it is document.save() or document.share(), other APIs such as
rather advisable to transfer image source URL instead of Image toolbar.matchBGColor() which are mainly presentation APIs
data. may be exposed directly to the content.
Exposing browser application feature along with many As a final result set we will evaluate our framework against
Android platform features to content Java Script requires existing approaches to prove completeness and competitive
security and access control to protect users and user data. capabilities. We compared bom/dom capabilities with various
browser’s extension framework APIs, as all these APIs are requirements. Since the framework is completely on Android
custom APIs which provide extended features in browser. application side it’s very easy to adopt and implement. We
Since our framework is on Android OS we took and compared also presented a developed content utilizing exposed API
similar features in Desktop browsers also. Some of the and finally we presented API execution time for various
features are Android Specific thus not applicable for Desktop input data sizes which will be very helpful for designing
browsers. Figure-8 shows the API comparison. APIs. As a future work the framework can be enhanced to
have more APIs along with their performance optimization.
The framework may also be ported to other platforms and
performance comparisons can be presented.
ACKNOWLEDGMENT
We would like to thank our colleagues Raghavendra
Ghatage, Manish Kumar and Joy Bose at Samsung Research
and Development Institute Bangalore for their timely guidance,
motivation and support.
REFERENCES

[1] [BOOK] Thomas A. Powell, The Complete Reference HTML & CSS,
Tata McGraw Hill
[2] JavaScript Online tutorial, http://www.w3schools.com/js/
[3] CSS Online tutorial, http://www.w3schools.com/css/default.asp
[4] Document Object Model, http://www.w3schools.com/js/js_htmldom.asp
Figure 7 JS to JAVA API call performance
[5] Browser Object Model, http://www.w3schools.com/js/js_window.asp
[6] NPAPI documentation https://wiki.mozilla.org/NPAPI
[7] XPCOM documentation, https://developer.mozilla.org/en-
US/docs/Mozilla/Tech/XPCOM
[8] Microsoft component object model, COM documentation
http://msdn.microsoft.com/en-
us/library/windows/desktop/ms680573(v=vs.85).aspx
[9] Amit Singhai, Joy Bose, RS Ramanujam, Implementation and Analysis
of Pluggable Android Applications, IEEE SPICES 2015, KERELA
INDIA
[10] Java Script API for chrome object, Online documentation at
https://developer.chrome.com/extensions/api_index
[11] Ming Jin, Tizen Web Run Time , Tizen Developer conference, May
2012
[12] Android Web View, Online documentation at
http://developer.android.com/reference/android/webkit/WebView.html
[13] Android Frame Layout , Online documentation at
http://developer.android.com/reference/android/widget/FrameLayout.ht
ml
[14] Document Object Model (DOM) Activity Statement, P. Le Hégaret,
June 2002. Available at http://www.w3.org/DOM/Activity
[15] Content View documentation at chromium open source project,
Figure 8 API comparison http://src.chromium.org/svn/trunk/src/content/public/android/java/src/or
g/chromium/content/browser/ContentView.java
V. CONCLUSION AND FUTURE WORK [16] The Android Developer's Cookbook: Networking By Ronan Schwarz,
Phil Dutson, James Steele, Nelson
In this paper we presented an application layer approach [17] Lei Shi, Cheng Niu, Ming Zhou , Jianfeng Gao, A DOM Tree
to extend browser’s BOM and DOM APIs as per vendor’s Alignment Model for Mining Parallel Data from the Web