Holiday Wish List for Browser Makers

Requirements for an Open Web

By Rajaram Gaunker.

Web applications are making quantum leaps in sophistication, complexity and functionality in
many areas they are surpassing traditional desktop applications. Increasingly powerful devices, a
wide variety of JavaScript libraries, and the growth of cloud-based services is transforming whats
possible with web applications.
Browsers play an important role in this world. Browser inconsistencies have plagued the web since
its early days. Microsoft tried to co-opt browser standards by leveraging Internet Explorer
dominance violating the HTML spec left, right and center. Then, with the arrival of Firefox,
Chrome and Safari, the browser landscape got even more interesting.
At the same time, websites were evolving. They began as simple, static web pages with little or
no JavaScript. Then HTML5 created the possibility of complex web apps on browsers. To add to
this, the appearance of mobile devices with full-featured browsers based on WebKit created
hundreds of new possibilities.
Yet as we approach 2015, incompatibilities still create hurdles in the development of complex
webapps. While DOM abstraction libraries like jQuery take care of most DOM-level inconsistencies,
some are still left for the developer to struggle with. While browser vendors are focused on
creating differentiation, users and developers are experiencing lock-in. This is a very serious
hurdle to the Open Web. Vendors should adopt open standards and differentiate themselves with
the Layout Engine and the Rendering Engine.
Let me get more specific now. During the development of our browser virtualization
client Nanovisor.js, we saw several issues on browsers which were inconsistent and sometimes
baffling. These issues forced us to have special-case handling for different browsers, which makes
code complex and difficult to maintain.
In this blog post, Id like to share some of these with you and give the browser makers my wish list
for the holidays. Heres to wishful thinking :-).

First, let me add a caveat to say that this is by no means an exhaustive list of the issues we have
seen. Ive selected a handful here to make some key points. Let me start with Safari since it is the
browser with the largest number of issues we faced, and is important from a customer deployment
perspective.

Source: NY Times

Wish List #1: Language-level consistency

Combining two statements into one is one of the most common and simple source-level
optimization techniques. But sadly, it does not work as expected on Safari.
Two simple statements are combined by the JavaScript code minimizer (Google closure compiler),
and that triggered the bug in Safari. A simplified version of the code is as follows:
var type = typeof document.all;

if (type === function) {

console.log(document.all is a function);
// Above log is not printed on any browser
}
But the closure compiler converted that code to:
if (typeof document.all === function) {
console.log(document.all is a function);
// prints above log message on Safari only
}
The above two code blocks are equivalent in all browsers except Safari. All other browsers I tested
on return typeof document.all === function as false; but Safari returns true, typeof
document.all which actually returns a different value based on surrounding operator, and
typeof document.all returns undefined on all the browsers.
This is a basic element of language consistency, and having a major JS engine that breaks this is
scary.

Wish List #2: Safari crashes

Another big issue we faced with Safari was the JavaScript interpreter actually crashing on some
piece of code. Such issues are very hard to debug, isolate and fix, especially for browsers that are
not fully open-sourced. Execution of Javascript is done in a sandbox and there are several levels
of abstraction between the executing code and the OS. Browsers should catch such errors and
provide enough data to debug them.
Safari has been crashing deterministically on some simple JavaScript code while the same code
runs well on other browsers. Many times, this looked on the surface like some bug in the
JavaScript JIT compiler. Heres a sample bit of code which caused the crash:
<html>
<head></head>
<script>
function foo() {}

window.addEventListener('DOMContentLoaded', function() {
var lis = [];

for(var i =0; i <200; i++) {

lis[i] = i;
}
Lisnew = Object.create(lis);
for(var i=0; i <

lis.length; i++) {

Object.defineProperty(Lisnew, i, {
get: function() { return lis[i]},
set: function(val) { lis[i] = val}
})
}

var obj = {};

foo.apply(obj, Lisnew);
});
</script>
<body>
</body>
</html>

Crashing of the browser has very serious impact as it cuts off a set of customers (OS X, iOS users in
this case) for webapp developers.

Wish List #3: Deprecating features flip-flop of Chrome, W3C and Firefox
Deprecation is part of spec development and needs to be done with extra caution, clear
communication, wider consultations and experimental analytics.
Earlier this year the W3C changed the DOM spec to remove Attr.ownerElement. Chrome followed
the spec, and released Chrome 34 with it removed and then added it back in Chrome 37.
Meanwhile Firefox removed it in 29 (Aurora) and reverted the change when the final version came
out.
This bug created much confusion, as different people were testing on different browsers.

The full story of this flip-flop can be seen in

W3C ticket 25086
Chrome ticket 353104
Firefox ticket 957431
The W3C, along with Mozilla, Apple and Google, drives the specifications. The occurrence of this
bug showed a lack of coordination between them.

Wish List #4: Yet another typeof difference on Firefox

There are several old problems for which no consensus has been reached for many years now.
The following inconsistency, for example, has been there since 2004 (the early days of Firefox):
HTMLObjectElement and HTMLEmbedElement provide interfaces to external content like Flash and
Java applets in browsers. If you do
typeof embedElement
it returns function when running on Firefox and object when running on the rest of the other
browsers.
According to the ECMAScript spec (11.4.3), the typeof operator on a native or host Object that is
callable should return function. Not all plug-ins are callable, but Flash SWF plugins are callable.
Other browsers return object for even callable plugins.

Conclusion
So there you have it. These are some of the top of mind issues that we encountered during the
Nanovisor development process that reinforce that writing cross-browser software is difficult,
frustrating, expensive, and thereby likely to drive lots of developers away from the web rather
than encourage them to embrace it.
It is high time that browser vendors come together and clear out these long-pending, annoying
inconsistencies. Thankfully Internet Explorer has been doing this starting with IE10. They are not
finished yet, but they have made a welcome start.
Consistent browser behavior is important and a requirement for the success of an Open Web.
Browsers riddled with inconsistencies will keep on eating away at developers time and money
(not to mention their sanity). Browser makers need to come together to remove older
inconsistencies with a mechanism that provides enough time for developers to eliminate
dependencies in their code that exist due to these.
Safari is the most inconsistent, crash-prone and buggy browser, well on its way to becoming the
IE6 of the HTML5 world. Chrome is trying to push the the native platform PNaCl. Perhaps their
intent is to create stickiness and trap developers to their app platform for their obvious benefit.
Yet, I would like encourage them this holiday season to take some decisive action on this front and
help create a world with consistent browser behaviors for developers and thereby, for everyone
that uses the Internet. I hope Im not dreaming of an impossible utopian world.