Chromium Developers: Wrangling Webkit Bugs

Sun, Apr 1, 2012

I did some thinking about managing such a big project like Chrome when it depends on such a big project like Webkit. Tons of Chrome bugs are actually Webkit bugs, or are related to Webkit bugs somehow, much like the one I encountered in my previous post. The Google Code project hosting doesn’t seem to have a great way to manage external bug dependencies not on Google Code as of yet, so I took it upon myself to write a tool to help Chromium developers find relationships between Chromium bugs and Webkit bugs. It’s a bit of Python and Javascript. I’m planning on releasing the source code soon, but the results are already online at http://stephensearles.com/chrome-webkit-bugs.

Just from the bit I’ve explored, there’s some rather astonishing findings. First of all, it looks like in virtually no case is there an open Chrome bug with a Webkit relationship that has been updated or commented upon more recently than its Webkit bug. This isn’t to blame the Chromium developers, because they’re likely fixing many of the Webkit bugs, rather, it’s a pleasant observation that when problems occur with Chrome, its developers seem to generally fix it at the source instead of writing some ugly workaround. That’s one possibility. Another observation is that many open Chromium bugs related to Webkit bugs, almost half of the ones I pseudorandomly looked at, are simply left open after the Webkit bug has been fixed. Sometimes for years. At least one of these required more work after the Webkit bug had been fixed, but presumably many many don’t. We’re talking about, if these statistics hold, 300 bugs that could just be closed right now. When was the last time the Chromium bug tracker had that good of a day?

Speaking of the Chromium bug tracker, if you take a close look at this scraped data, sort by the last updated project and you’ll find that there are some that have Chrome marked as their most recently updated, but because there are no Webkit bugs! How did this happen? Well, two things, and two potential issues in Google Code. First, there’s a little issue with how Google Code displays comments. It wraps them all in

 tags, which is how Google Code seems to display HTML source. Pretty common for talking about a browser. When it linkifies URLs, however, it makes errors when the URLs are wrapped. In the cases I’ve seen (example), it’s happening about the “?” of the query parameter, so it could be a regular expression error or something to do with anchor elements inside pre elements. The second Google Code bug is more nebulous to me. If you look at those roughly 40 bugs with no Webkit bugs referenced in the list, many of them actually have no Webkit bugs referenced in them! This surprised me, because to get my list, I’m using Google’s search. My query exactly is “bugs.webkit.org/show_bug.cgi”, and though I’m using the API, it’s curious why Google’s search is returning, what seems to be, false positives. Looking closer, the bugs referenced usually have some other bug tracker with a “show_bug.cgi” link, so it’s just using the slash as a word boundary and searching the two sections independently. This is something I could likely address with more clever searching and data processing, but I also wonder if there’s a literal search option that’s just not made obvious. So if you know anyone who works on Google Code itself, things to look at…


So I hope this helps out someone working on Chromium. Give me a shout if you find it particularly useful or if you have ideas for expanding it. I’m thinking about a few things like an auto-commenting bot (which may be too intrusive) or an RSS feed. I’d love to hear any thoughts. It seems like there’s so many simple things that could be fixed, or at least kept tabs on better, with a bit more information.