Holiday Wish List for Browser Makers – Requirements for an Open Web

1
HOLIDAY WISH LIST FOR BROWSER MAKERS
REQUIREMENTS FOR AN OPEN WEB
BY RAJARAM GAUNKER
2
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.
3
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 onWebKit 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.
Source NY Times
4
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.
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
5
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.
6
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
lthtmlgt ltheadgtlt/headgt ltscriptgt function foo()
window.addEventListener('DOMContentLoaded',
function() var lis for(var i
0 i lt200 i) lisi i
Lisnew Object.create(lis) for(var
i0 i lt lis.length i)
Object.defineProperty(Lisnew, i,
get function() return lisi,
set function(val) lisi val )
var obj foo.apply(obj,
Lisnew) ) lt/scriptgt ltbodygt lt/bodygt lt/htmlgt
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.
7
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.

8
WISH LIST 4 YET ANOTHER TYPEOF DIFFERENCE ON
FIREFOX
Deprecation is part of spec development and needs
to be done with extra caution, clear
communication, wider consultations and
experimental analytics. 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 HTMLEmbedE
lement 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.
9
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 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.
10
www.instartlogic.com/blog/