Extensions in Opera

An alpha of Opera 11 for desktop was just released by the Desktop team. One of the major new changes in this version is support for Browser Extensions, a feature we have been working on in Core for some time now (see also the API documentation).

When implementing Browser Extensions, we wanted to re-use as much as possible of the Web platform we already support in the Opera core. We found that our implementation of the W3C Widget family of specifications was particularly well-suited for the task. Unlike the packaging formats that other browser makers are using, these specifications give us a W3C standardized way of packaging software based on web technologies such as HTML, CSS and JavaScript. ...


By utilizing the W3C Widgets specifications for both Widgets, Unite Applications and now Browser Extensions, we make it easier for developers, as there is only one format to learn. It also allowed us to use the same back-end code for managing all of them. To differentiate between the package types, we look at the media type of the package.

While looking very similar on the surface, W3C Widgets and Browser Extensions have very different scopes. W3C Widgets run as stand-alone applications in the operating system, and can access system resources like other applications. Browser Extensions, on the other hand, run inside the web browser, and have access to parts of the browser user interface and the pages that are being displayed to the user. In practice, this means that we enable a few additional proprietary APIs and functionality for Extensions that are not commonly found in W3C Widgets.

When laying down the groundwork for Extensions, we have worked hard on getting our base Widget support more in-line with the W3C Widgets specifications. The version you are looking at is the Opera release with the best and most up-to-date support for these specifications so far.

Simplifying User scripts

We decided to implement Extensions in Opera bit-by-bit, from the ground-up. Since we already had support for W3C Widgets, this gave us support for installing and uninstalling Extensions, essentially just by adding detection of the media type. Just being able to install and uninstall them was not very interesting, so we looked at what kind of "extensions" we already have available today. In the most basic form of Browser Extensions, we use them just for packaging User JavaScripts.

Support for these technologies has been around for a while, and while they are relatively easy to develop, they can be difficult to install, distribute and share. By allowing Browser Extensions to package JavaScript we can solve that problem, making them one-click installs.

For those of you who have been around for a while, you have seen snapshots of our internal development version, which is our primary testing platform here in the Core department. It is a bit clunky, but by implementing support for Browser Extensions, we have been able to test the feature from the ground up. It also means that we have been able to play with them even before the Desktop team guys got their hands on it.

Adding buttons

But just packaging User JavaScript will not allow you to make very advanced extensions. We also need a way to extend the user interface. To do that, we have created the uiitem specification which allows you to easily create context menus for a given context.

Putting the following snippet inside a <script> tag of the index.html file will add a simple button to the user interface.

var toolbar = opera.contexts.toolbar
var props   = { title: "My first button" }
var uiItem  = toolbar.createItem(props);

The button will not do anything, as we have not defined any interaction in the example, but it is a start.

Packaging the extensions

If you know how to make a W3C Widget, you know how to make an Opera Extension. Just like them, Browser Extensions use HTML, CSS, JavaScript and the DOM to get the work done.

For simple extensions that just package User JavaScript, it is even simpler. Just put the scripts in the "includes" folder in your Extension archive, add a simple config.xml file and an empty index.html at the root, create a ZIP archive of all the files (be careful to make sure the config.xml is at the root of the ZIP archive) and rename the file so that its file extension is "oex" (for Opera EXtension; Windows users may need to disable the Hide extensions for known file types feature first). This file can now be installed, for instance by dragging and dropping it over your Opera window.

You can easily tests your scripts before creating the extensions using the standard User JavaScripts feature.

If you want to play with buttons, there is more work to be done. You will need to embed a script not unlike the one above inside either the (previously empty) index.html file, or a file linked from it. Once you have done that, you create the ZIP file, rename it, and install it as above. For more details, please see the API documentation.

To make Browser Extensions available to others, you can put them on a web site, making sure they are served with a media type of "application/x-opera-extension". We are also working on a repository where you can share your extensions with others.

The future

As mentioned above, we are building Browser Extensions piece-by-piece, so that we have a solid ground to build on before we add on all the bells and whistles that are necessary for those great super-extensions we know are lurking out there, just waiting to be written. We have some good ideas cooking already, but we will also use feedback on the alpha release so that we can implement the things you care most about.