Sprocket - Experimental Multiplatform Browser Based on Content API

Several months ago, a simple question was raised to us: How can one build a web browser? This was an interesting question not a trivial one to be answered in one sentence. So, at the University of Szeged we started to work on this issue to come up with a handy answer. This is how Sprocket was born. However, let us start from the beginning.

You can start from several perspectives. The main question is whether you want to build a browser on top of any current rendering engine, or you want to build a completely new browser and every component from scratch. If you choose to build a totally new browser, check out this tutorial. For those who would like to follow the beaten path, open source communities have already provided several high quality browser engines: WebKit (Safari), Blink (Chromium), Gecko (Firefox), Servo (Mozilla’s experimental project). There are also several other popular "out-of-the-box" solutions: CEF, NW.js (previously node-webkit), Awesomium, OpenFin, QtWebEngine. Each of these are using their own UI, callbacks, and ecosystem to support different purposes.

We have chosen the Content module to show the way to build up a browser. It has a nice API and several good documentations since the Content module is part of the Chromium project. We have spent some time looking for an accurate tutorial which describes how the Content API can be used to build up a browser, but we noticed that no such detailed guide exists. So, we decided to fill the gap and start a project on this topic. The main goal was to build an experimental minimal browser and write a detailed tutorial about it, so that anyone could build his/her own unique browser or even embed it.

From the technical perspective, the Content module is responsible for rendering a webpage using a multi-process sandboxed browser. It supports HTML5 and GPU acceleration as well. If you would like to read further details, you can check this out. The source of the Content module can be found in Chromium’s source (src/content). The classes in the content/public folder can be inherited in order to implement the required specific behaviours.

Our experimental project is named Sprocket. It supports multiple platforms: ARM (Android, Linux), PC (Linux), and our main goal is that the project should be as minimal as possible compared to the existing implementations. In the project, code size is reduced to a minimum, and unnecessary requirements are dropped. Now, we are continuously extending Sprocket with well-documented new features. We have finished the following milestones:

  • Basic codebase - stable minimal browser on Linux (PC and ARM)
  • ARM Android support
  • Sandboxing (Linux)
  • Tab support (Linux)
  • JavaScript dialogs (Linux)
    • alert, confirm, prompt, unload
  • Authentication dialog (Linux)

Currently, we are working on tab support for the Android version. The following additional features are planned to be supported in the future, but we are open for any suggestions from the community:

  • Error Page
  • More dialogs
  • Custom URL scheme handler
  • Settings
  • History
  • Downloads
  • Bookmarks
  • Incognito mode (private browsing)
  • Custom UI

Here are a few screenshots of Sprocket on different platforms:

If you are interested, you can check out our GitHub repository here. We are pleased to accept any contribution. You can also check out our more detailed documentation about the current state of our project.

In the future, we plan to create a series of documents in order to oversee and share our process and achievements, and we shall also provide detailed tutorials for the community about the implemented features.

On behalf of the Sprocket team,

Edit Balint

Anonymous (not verified) - 08/31/2015 - 13:12

Do you plan to implement headless browser? I mean, that no X would be required, and it can be controlled with a simple API - this could be nice for simple testing...

edit.balint - 09/23/2015 - 14:01

I think that a headless browser like you mentioned could be useful for servers, but you will miss a lot of good and standard features because of the missing renderer (for example: WebGL, Canvas, DOM Object updates or any related JS functions). On the other hand implementing a browser port with full software rendering for such a complex system as Content API is, needs a lot of time and effort. Currently our targets are desktop and embedded systems. Probably later we can have such a port, who knows?

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • No HTML tags allowed
  • Lines and paragraphs break automatically.

More information about formatting options

This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Fill in the blank