Contributing to Chromium

I always wanted to work on a web browser. Probably because I’m both a front-end focused web developer and a low-level loving C++ programmer, and web browsers are among the few types of software that require such a combination.

Moreover, I recently felt the urge to lay hands on large, established code bases. I believe that working with existing code will take me further in my quest of becoming a better programmer than starting yet another small project. So I decided to contribute to Chromium, the open source project behind Google Chrome.

Why Chromium?

Well, mostly because it’s my favourite browser, and because it is in my opinion the one that pushes the web the most right now. I also think that a few more non-Googlers working on it would be good for the project. Not that I distrust Google on this, but I believe that an open source project, especially such an important one, needs contributors from all over the industry. A too dominant player can, even with good intentions, harm a project in the long run: Remember what has happened after Oracle bought Sun.

Another reason why I picked Chromium was that I thought it was a small, modern, lightweight piece of software, unlike Firefox, whose code base appears to be an ancient monster. Guess what? Chromium’s code base is a monster too, at least in terms of size. Including dependencies, we’re talking about several gigabyte of source code here.

The code

Nonetheless, the code quality looks good to me. Google’s (partially weird) code style is followed consistently and the code I’ve seen so far looked clean and polished. I don’t understand the complete architecture yet, but what I’ve seen and read seems promising. I have only two problems with the code:

Monolithic build

I found it difficult to work on just one area, in my case the UI. You have to statically link all of Chromium (which takes about 10 minutes on my, admittedly slow, netbook) in order to see even a small change. I would prefer it if there was some way to fiddle with design and layout with a faster turnaround. Some people on the #chromium IRC channel seem to be unhappy with this as well.

Redundant UI code

Considerable parts of the UI code are effectively duplicated for each supported platform: Windows, Mac and Linux. The Windows code is written with WinAPI and WTL, the Mac code with Cocoa and Objective-C and the Linux code with GTK. I’m sure they have their reasons, one of which is very likely performance, but I still think there could be more code reuse among the platforms. I have seen essentially the same code on different platforms, written in a slightly different way, probably by a different person. As is the problem with code duplication like this, some bugs get fixed only in some versions of the code. The status bubble (the thing that appears if you move the mouse cursor over a link) is a good example of this: It slides perfectly on Windows, flickers a bit on Mac and disappears completely on Linux.


In order to find something to contribute, I had a look at the Chromium issues marked as GoodFirstBug and picked one that concerned the sliding of the status bubble (see above) on Linux. After identifying the problem and fooling around with the code, I noticed that this was a non-trivial GTK problem, the kind of thing I’d like to avoid with my first patch, not having used GTK before. So I picked an issue with the downloads tab which was all in all about one hour of work, naturally not counting compilation time. To my delight, the download tab’s UI was written in HTML/JS, which made the UI work a no-brainer.

It was fun to work with the code, but the compile times were pretty annoying. My desktop box at home is quite fast, but I rarely use it ever since I became a dad. So I worked on the train, which means on my netbook. I usually don’t have any problems programming on it – even Eclipse is usable – but Chromium development was tough. A trivial change meant that I would have to wait for 10-15 minutes. A git pull meant that I had to compile over night. It was mind-numbing.

Was that worth it? Yeah. Sure, my issue wasn’t a big deal, but now I can tackle more difficult ones, maybe even become a committer if I stay motivated. That would allow me to shape the future of the web, which is a considerable level-up for a web developer. Not sure if I can keep my motivation when having to work on that slow netbook though. Maybe I can use some of the 20% time at work for this, I guess Chromium development would be much more enjoyable on a powerful iMac.


My company being awesome, I was indeed able to hack on Chrome during 20% time. I implemented Kiosk mode for Mac. As expected, it was more enjoyable with the iMac. I have a lot of 20% projects going on, but I’m definitely planning to contribute more in the future.

Leave a Reply