Opera Core Concerns

You know the complexity of web technology is getting out of hand when every website needs some special treatment. Imagine driving a car if you had to change the engine slightly or replace wheels every time you turned a corner and entered a new street? Browser development is a lot like that these days.

Nearly every modern browser has site patching features, to grease the wheels where the nuts and bolts of standards are exposed to the unpredictable elements of the web:

• IE8 shows sites on the compatibility list in IE7-mode
• Google Chrome spoofs on Hotmail
• Safari has obscure, un-documented site-specific hacks
• Firefox apparently only has the User Agent switcher extension - but it is extremely popular in spite of its niche audience.
• Opera has user agent spoofing and browser.js

Treating every site differently? That sounds insane. It's clearly impossible. For starters, there are billions of websites, all different. And they keep changing with millions of lines of code being added or changed every day. Who can possibly keep up with that? Besides, aren't standards supposed to be the answer?

Standards

I commend the standardisation efforts and the evangelists at The Web Standards Project and elsewhere. Without you we would be far, far worse off. The future might even be on your side - more and more sites validating and cleaning up their standards story. Power to you!

Various Opera teams take part in the standards work too, including doing education and outreach. Our Open The Web team contacts web sites with advice on cross-browser compatibility and standards compliance.

But the browser is the user's agent. Across all sites breaking the rules and standards in different ways, we owe the user to do anything we can to make them all work whenever possible. Often a broken site is not our fault, but it's most definitely our problem. And we must make it work today. Not in 2022..

Hence, we patch.

Since we see various more or less ad-hoc approaches to site patching develop among our fellow browser vendors, it seems like a good time to share some of our experiences - what I think are the strengths and constraints of our particular implementation.

Strengths

Experience

Opera has more experience with site-specific patches than other browser vendors, since we've been patching the web since Opera 8.01. I believe our solution is also by far the most advanced one. Special commands available to User JavaScripts make up a simple yet powerful API for modifying and correcting a website. With getters and setters and DOM interfaces we can change Opera's behaviour to match most standard deviations the script expects. Sometimes we add a specific missing style or even remove some object or policy that gets in the way. And when a web site uses browser sniffing we can often dig in and repair the exact line of code that is broken! Some random examples:

• We can add the single missing class name when AOL Japan abuses browser detection and doesn't apply correct styles, and correct AOL webmail's spelling mistake when they spell dojoType as dojotype.
• We can fall back to a graceful postMessage() call when E*Trade tries to violate the security policy against navigating another site's frame when it loads encrypted content

We can also override settings like what browser we identify as and what rendering mode (quirks or standards) we should use for a specific site through downloadable preferences.

Bugfixes

Given the power to change websites and change Opera, we can sometimes even work around our own bugs.

• When the menu on weather.com disappears because mouse events happen in the wrong order, I can re-order them
• When search results on Google Codesearch appear as white-on-white I can re-style them

Now there's a thought. Opera - the browser that works around its bugs so you don't have to? This is like a time machine - we can fix our past sins for already released versions.

In the long term, this is a very important and subtle effect of browser.js: there will be less Opera-specific hacks to worry about. Both IE8's upgrade woes and our own experience tells us that workarounds against our own old bugs are among our worst problems. We did the wrong thing, sites did the wrong thing in response. We fixed it on our side, but the web never forgets your old bugs.

The difference with browser.js? When we release a new version with bug fixes, corresponding browser.js patches are secretly dropped as obsolete. What used to work because of browser.js hacks keeps working because the new version supports it, making the upgrade experience smoother for users and web developers alike, and a lot simpler for us. I can almost feel the envy of the IE8 team across the Atlantic.

Another interesting effect is that we can implement new standards with less worries. When HTML5's <input required> feature breaks Barnes & Noble because the user name field in the login form isn't really required input after all when you click the "create account" button - we can first patch it, and later tell the spec editor about our problems and discuss if the spec can be made more web-compatible.

Transparency

From the very beginning, one of the main concerns was that our fixes would prevent webmasters from finding and correcting problems. We might even end up creating problems if our patches linger on while the site changes.

To make things as transparent as possible, the patches are documented, we try to keep the file itself readable and reasonably well commented (though we also try to avoid unnecessary download bloat). And every patch applied will output a message in Opera's error console trying to make it obvious what is going on.

Scope

Site patching is cross-platform. Actually, that's an understatement. Did you know we have site patches for Nintendo Wii? And for the DSi? For Opera on Windows Mobile, Symbian, BREW and Archos's portable media players? Heck, we even have patches for Opera Mini!

• When Hotmail and Yahoo mail require rich text editing to compose E-mail we can fake rich text support even on devices with input and CPU limitations where rich text support is impossible
• If Facebook's fancy animations take too long to run for the Opera Mini server - it needs to pass content on to the actual client after all - we can cut them short and yet perform the important actions Facebook saved for the end of the animation.

It's an ambitious scope, probably much more ambitious than it might seem from the outside. The devices and platforms have very different requirements and problems. For example:

• On the Wii we have a minimum font size to keep things readable - but this often causes unexpected widths, wrapping and repositioning content in ways that don't happen on a Desktop browser. We patch several sites that have too rigid positioning to accomodate a slightly larger font size.
• Using an on-screen keyboard on the Wii and many mobile phones means the window resizes itself every time you focus a form element - to make room for the keyboard. When British Airways re-loads the booking page every time you resize it, booking a ticket with a virtual keyboard becomes pretty hard...
• ..and when eBay in France tries to count your keydown events to make sure you don't cheat and paste your e-mail address into the registration form's "re-type E-mail" field it won't work with on-screen keyboards either. Some of them just don't support key events. Come on eBay, I really did type it in. I mean, REALLY! On hardware where cut-and-paste isn't even AVAILABLE!...

When dealing with such a range of problems the true and magic potential of browser.js becomes apparent.

Infrastructure

To support all this, we need some nifty download servers picking the correct file for any client that asks for one. We have a database of patches and meta data like what versions and platforms a patch applies to. But did you know we also have a script spidering sites to check if broken parts are still there? When a patched site changes a relevant piece of code, I want to know about it. I love the sound patches make when they hit the virtual "obsolete" bin.

Constraints

Time

So much power, so little time.. Analysing sites and developing patches takes a lot of time. We are nowhere near IE8's overwhelming list of 2400+ sites. (Actually, browsing the IE8 list is a Déjà vu experience. Many familiar names, many sites we need to patch or contact for various reasons too.)

Nevertheless, our list is shorter - fortunately! Technical analysis with the level of detail required to support our site patching can be very time consuming, so I hope we'll remain smaller and more focused than the IE list. We will however scale the efforts up - we're at 600+ entries in the database and there is room for plenty of more - and we welcome contributions.

Performance

I just said there is room for plenty of more patches. But how far can we scale site patching before performance suffers too much?

Apparently we can keep going for quite a while. Some profiling work we did recently indicates that we can patch upwards of 10 000 specific sites without slowing Opera down by more than a couple of percentage points. And frankly, by the time we've written patches for 10 000 sites you've probably bought a more powerful computer..

Security

Isn't it unsafe? Can't a virus or malicious server fake your browser.js file and gain instant control of your Opera browsing?

The short answer is: no.

The longer answer is that this would be possible without our security precautions, but it is in fact all taken care of. Every file is signed, so Opera can check that it is a genuine file and that it has not been tampered with. Such a signature is very, very hard to fake. If a malicious server or virus alters the file, Opera will stop using it and try to download a fresh version from the server.

Conclusions

One of the things that surprised me most about browser.js work is how quickly the web changes. By paying such close attention to specific sites we see the web as a whole evolve, and it's iterating faster than I would have dared to expect. And contrary to what you might expect, we do see sites change to become more Opera-friendly after we've patched them!

That means site patcing works. It works because it improves compatibility, thereby giving users a real choice in browsers and - as weird as it may sound - as a direct effect of that, it gives webmasters incentives to make sure their sites are Opera- and cross-browser-compatible.

Welcome to the future - made of and with standards, openness and site patching.

About the author

Hallvord R. M. Steen works for Opera's core team on quality assurance, testing and web compatibility. He maintains the browser.js file and can break all websites worldwide with a minor typo.

To make sure new versions of our browser core are of sufficient quality before making their way into any of our products, we run more than 100,000 automated tests on a number of different reference configurations every time we have a new build.

We run automated visual tests, JavaScript tests, selftests, performance tests, stability tests, memory tests and a lot more. One thing we have been missing, however, is automated tests for the things that require some sort of user interaction--clicking links, filling out forms, interacting with complex Web applications.

That is ... until now.

We are working on adding support for driving the browser through our scope protocol, which is the same protocol we use for the Opera Dragonfly debugger. Through a simple script, we can instruct the browser to automatically to search Google, log into Hotmail and send a message, buy books at Amazon or find plane tickets at Expedia.

Here's an example of what such a script can look like:

require "operawatir"

browser = OperaWatir::Opera.new
browser.goto("http://www.google.com")
browser.text_field(:name, "q").value = "Wikipedia"
browser.button(:name, "btnG").click

browser.link(:text, "Wikipedia").click

puts "PASS" if browser.text.include? "Wikipedia"

The syntax above is that of the Watir API, a Ruby test tool originally developed for Internet Explorer that is now being ported to Opera and other browsers.

Below is a video of the script running in the desktop version of our browser. We've had to slow it down significantly for you to be able to see what's going on - the test normally takes a few hundred milliseconds.

Through scripts like these, we can automatically test many of the things our millions of users do every day. If we break anything and a test fails, our scripts will instantly notify us so that we can fix it.

But testing these things on our x86 test builds is not enough. We ship on hundreds of different devices every year and need to run the same tests on many different platforms to make sure everything is still working after porting.

When using the scope protocol, it doesn't really matter if you're talking to an Opera instance locally or remotely; it was built for working on any device. Here's the exact same script running on a mobile phone:

Shortly after we started working on this tool, we figured that this might not just be useful for us testing our browser engine, but for Web developers testing their own Web applications, too. Our new tools are still in a pre-alpha stage, but as they mature over the coming months, we would like to make them available to all of you as well.

There are several different browser drivers out there, and we would like to support the most popular ones. The script above was using the Watir API. The following script is doing the same thing through Webdriver, which will be used in the next version of Selenium:

public class OperaDriverExample  {
    public static void main(String[] args) {
        WebDriver driver = new OperaDriver();
        driver.get("http://www.google.com");
        WebElement element = driver.findElement(By.name("q"));
        element.sendKeys("Wikipedia");
        element.submit();
        WebElement wikipediaLink = driver.findElement(By.linkText("Wikipedia"));
        wikipediaLink.click();
        System.out.println("Page title is: " + driver.getTitle());
    }
}

Over the past few months, a small team of developers and testers have been working on implementing a new ECMAScript/JavaScript engine for Opera. When Opera's current ECMAScript engine, called Futhark, was first released in a public version, it was the fastest engine on the market. That engine was developed to minimize code footprint and memory usage, rather than to achieve maximum execution speed. This has traditionally been a correct trade-off on many of the platforms Opera runs on. The Web is a changing environment however, and tomorrow's advanced web applications will require faster ECMAScript execution, so we have now taken on the challenge to once again develop the fastest ECMAScript engine on the market.

The name Carakan, like the names of Opera's previous ECMAScript engines, Futhark, Linear A and Linear B, is the name of a writing system, or "script".

We have focused our efforts to improve upon our previous engine in three main areas:

Register-based bytecode

The last couple of generations of Opera's ECMAScript engine have used a stack-based bytecode instruction set. This type of instruction set is based around a stack of values, where most instructions "pop" input operands from the value stack, process them, and "push" the result back onto the value stack. Some instructions simply push values onto the value stack, and others rearrange the values on the stack. This gives compact bytecode programs and is easy to generate bytecode for.

In the new engine, we've instead opted for a register-based bytecode instruction set. In a register-based machine, instead of a dynamically sized stack of values, there's a fixed size block of them, called "registers". Instead of only looking at the values at the top of the stack, each instruction can access any register. Since there is no need to copy values to and from the top of the stack to work on them, fewer instructions need to be executed, and less data needs to be copied.

Native code generation

Although our new engine's bytecode instruction set permits the implementation of a significantly faster bytecode execution engine, there is still significant overhead involved in executing simple ECMAScript code, such as loops performing integer arithmetics, in a bytecode interpreter. To get rid of this overhead we are implementing compilation of whole or parts of ECMAScript programs and functions into native code.

This native code compilation is based on static type analysis (with an internal type system that is richer than ECMAScript's ordinary one) to eliminte unnecessary type-checks, speculative specialization (with regards to statically indeterminate types) where appropriate, and a relatively ambitious register allocator that allows generation of compact native code with as few unnecessary inter-register moves and memory accesses as possible.

On ECMAScript code that is particularly well-suited for native code conversion, our generated native code looks more or less like assembly code someone could have written by hand, trying to keep everything in registers.

The register allocator is designed to be architecture independent, and so is the code generation "frontend" where most of the complicated decisions are made. We have initially implemented a backend for 32- and 64-bit x86, but some preliminary work has already started to generate native code for other CPU architectures, such as ARM.

In addition to generating native code from regular ECMAScript code, we also generate native code that performs the matching of simple regular expressions. This improves performance a lot when searching for matches of simple regular expressions in long strings. For sufficiently long strings, this actually makes searching for a substring using a regular expression faster than the same search using String.prototype.indexOf. For shorter strings, the speed is limited by the overhead of compiling the regular expression.

For more complex regular expressions, native code generation becomes more involved, and improves performance less since the regular expression engine is already reasonably fast. The base regular expression engine is a newly developed one, but it's already made its debut in Presto 2.2 (the browser engine used in Opera 10 Alpha). It's fundamentally a typical backtracking regular expression engine, but does some tricks to avoid redundant backtracking, which usually avoids the severe performance issues a backtracking regular expression engine can have on specific regular expressions.

Automatic object classification

Another area of major improvement over our current engine is in the representation of ECMAScript objects. In the new engine, each object is assigned a class that collects various information about the object, such as its prototype and the order and names of some or all of its properties. Class assignment is naturally very dynamic, since ECMAScript is a very dynamic language, but it is organized such that objects with the same prototype and the same set of properties are assigned the same class.

This representation allows compact storage of individual objects, since most of the complicated structures representing the object's properties are stored in the class, where they are shared with all other objects with the same class. In real-world programs with many objects of the same classes, this can save significant amounts of memory. It can be expected that most programs that do create many objects still only have a few different classes of objects.

The shared lookup structures for properties also allow us to share the result of looking up a property between different objects. For two objects with the same class, if the lookup of a property "X" on the first object gave the result Y, we know that the same lookup on the second object will also give the result Y. We use this to cache the result of individual property lookups in ECMAScript programs, which greatly speeds up code that contains many property reads or writes.

Performance

So how fast is Carakan? Using a regular cross-platform switch dispatch mechanism (without any generated native code) Carakan is currently about two and a half times faster at the SunSpider benchmark than the ECMAScript engine in Presto 2.2 (Opera 10 Alpha). Since Opera is ported to many different hardware architectures, this cross-platform improvement is on its own very important.

The native code generation in Carakan is not yet ready for full-scale testing, but the few individual benchmark tests that it is already compatible with runs between 5 and 50 times faster, so it is looking promising so far.

My name is Tim Johansson, I am a core technology developer at Opera. I work in the core graphics team which is responsible for all the rendering (of web pages, SVG and <canvas>) and image decoding in Opera.

In the middle of December Opera had an engineering seminar outside Oslo in Norway. At the seminar there were a few presentations. I gave a presentation about graphics in Opera and showed a few demos. In this post I will write about two of the demos, and link to videos of them.

Opera Flashlight

One of the first assignments I had at Opera was to work on a technology for platform independent graphics, which is now used in some of Operas products including the Opera SDK.
When working on it I quickly realized that this technology would make it easy to upload Opera to a texture in a 3d application.
Since I had been working on a 3d engine for fun in my spare time I spent a late evening integrating Opera into my 3d engine. The place I thought sounded most fun to add it was as the projective texture used for the flashlight in the 3d engine.

This video demonstrates the result of that late night hack more than 3 years ago.

Hardware acceleration

One of the things I have been working on lately is hardware acceleration of the vector graphics library used for SVG and <canvas> in Opera using 3d hardware (through OpenGL and Direct3D).

In order to get the most performance from rendering SVG/<canvas> in hardware it is good to avoid reading the rendered image back from the graphics card to system memory since that is a slow operation.
This can be solved by rendering all of Opera (including UI and web pages) in hardware. Rendering Opera in hardware also makes it possible to add visual effects without any additional CPU cost.

This video shows a demo of Opera running fully hardware accelerated. The demo build used in this video is an interal Opera core technology reference build with hardware acceleration enabled. Hardware acceleration is still experimental and is not in any released or soon to be released products.