Chromium Notes

Latin-1 decoding change

2010-03-04T18:57:1267729020Z

Originally I started this blog with the intent that each post would be about a particular commit. Here's a post back in that vein, about a change I had no involvement in but thought might be of interest to you:

WebKit bug 35233 -- Optimize Latin-1 decoding in TextCodecLatin1::decode()

How many ways do I like this change?

Nokia wrote it but we all benefit from it;
C++ master Darin proposed a template-hacker modification to it that makes it type-safe without losing the speed benefit;
The precommit bots that Googlers wrote caught that an earlier version would've broken the 32-bit Mac build;
The patch itself is a simple but clever low-hanging-fruit optimization.

The only piece it's missing is a regression test, but I guess WebKit currently doesn't have a lot in the way of performance regression tests.

PS: Since I'm again deep in a free-software lovefest, I'll just bury here that it's also pretty neat that Mozilla is both using bits of Nitro (one of the many confusing names of the Apple JavaScript engine) for improving JS speed and bits of Chrome for its out of process plugins. My mind circles around all of the biological metaphors we use for these things -- source trees, cross-pollination of ideas -- and I feel briefly like I'm living in the future.

Reload

2010-02-18T03:55:1266465300Z

What does the reload button do? Well, it reloads the page, obviously. Or at least that was about how far I had thought about it when I thought to poke into fixing the age-old "Chrome should support shift-reload" bug and I discovered there's plenty of subtlety in even a simple-sounding feature.

RFC 2616 (the HTTP 1.1 spec) has a section 14.9.4 titled "Cache Revalidation and Reload Controls" specifically discussing the various meanings "reload" could have. But rather than dive into that, another way of looking at it is to think about it from the user's perspective.

One use case is: I'm looking at a live blog or a stock ticker site and I think they may have updated something on the page. I want to go out to the site and ask it if it has anything new, but I don't want to redownload the stuff (like, say, the site logo) that I already have. That is, I use the existing HTTP support for If-Modified-Since or ETag and just request that the site (and any caching layers in between me and the site) go check if there's anything new for me and show me if so, and the same for subresources.

In a perfect world where caching is done correctly, I think that is all you would ever need. But that leads to the other use case, which is: something has gone wrong in the caching, and I want to flush all caches (both local and held by proxy servers). Here, you request the resources along with the appropriate HTTP headers to instruct everyone along the line to please not use their caches.

These two cases are intended to correspond in Chrome to the refresh button versus holding shift and hitting the refresh button. And though I fixed the bug, my work was just to plumb the shift state down to a flag passed to WebKit, and Darin suggested there are still WebKit bugs in this area.

How do we at least compare to other browsers? I don't know; there is more depth I haven't fully thought through. For example, suppose a server does the common JS/image caching trick where they provide headers that say the resources never expire and then just use a new URL when they want to change the resources. When I do a normal refresh, should I even go out to the network to see if those were modified? How about when I just hit enter in the URL bar of the currently-displayed page: should I just load everything from on-disk cache? (I believe that's what we'd do when you hit the back button.) Which behavior does the meta refresh tag do? And most importantly, how can a normal human being user understand all this?

From this I mostly conclude that web stuff is always more subtle than you'd expect. I came into this thinking that reload meant "go fetch the resources again as if you hadn't fetched them before", but learned that neither plain reload (which will allow servers to tell you to reuse your existing cached entries) nor shift-reload (which includes extra headers to try to get intermediate caches to drop their copy, something that even a first-time load won't do) does that. And also I learned not to trust browsers when they claim they've reloaded something.

WebKit commits followup

2010-02-08T18:45:1265654700Z

Ugh. Unfortunately, just as I had worried, my previous post was taken the wrong way (by TechCrunch). As the long list of caveats were trying to point out, I wasn't trying to frame a Google versus Apple story; aside from the many things wrong with counting commits that I tried to disclaim in that post, there's also a ton of other work that is not even hinted at in that metric.

For example, pretty much every change I've made to WebKit that isn't Chromium-specific has been reviewed by Apple employees; poor Darin Adler has probably invested about 50% of the time I did in reading through the patches I wrote, giving me feedback, and dealing with fallout when they break.

For another example, consider all of the hosting infrastructure (the website, the buildbots, the paperwork of granting people commit access). Or who answers all the questions on the mailing list.

For the record, what I was trying to say with that graph is: isn't it neat that there are so many other contributors to WebKit and that their involvement is growing? There are few (if any) other free software projects in such a healthy state -- the Linux Kernel comes to mind.

If anything, the only competition story in this is that this "coopetition" makes the web evolve faster and in a better way. By virtue of a shared source tree we're compelled to improve Safari/iPhones/Blackberries/etc. as we improve Chrome, with the benefit of experienced browser developers santity-checking the work as we go.

Who develops WebKit?

2010-02-06T19:33:1265484780Z

Edit: I wrote a followup to this post. Please read that before jumping to conclusions.

Who develops WebKit? Open-source projects that come from a single company typically have trouble attracting contributors from outside, but WebKit seems more successful than most in broad usage and contributions from both the industry and enthusiasts. I was curious about the trends of the project so I thought I'd dive into the commit history.

I hesitated to post this because it's easy to misinterpret. So please read the following carefully before jumping to conclusions. I am skeptical it is possible to measure contribution in a meaningful way; counting lines of diff credits people who make whitespace changes too heavily and penalizes people who spend weeks tracking down a subtle bug that results a one-liner change, while tracking commit counts weights people who commit frequently (e.g., Git users) more heavily. With that said, surely either way of counting at least correlates with investment.

Furthermore, Apple has had a working WebKit port since the first release of Safari, so the majority of continuing work that Apple does is core features that benefit everyone: all of that yummy stuff like CSS3 gradients and transforms. The work of ports (including Chromium) is primarily adapting WebKit to the particular platform, which only benefits the port. (Though as I mentioned earlier Google is gradually migrating towards more core features -- I missed a bunch in that earlier list, including web forms 2 and Gears-derived HTML5 features like storage/database/app cache.)

Finally, it's difficult to credit the work of many people to a particular company, as companies tend to hire from the talent pool of existing WebKit hackers, and people like Eric worked on WebKit at Apple, then at a startup, now on WebKit at Google. I took the easy way out and credited these to the latest applicable company; for example, the work done Qt hackers on WebKit before Nokia acquired Trolltech are credited below to Nokia, which isn't accurate.

Ok, enough disclaimers. Here's a graph of commits/day with some of the heavier committers split out into separate lines. I still think it's interesting despite its many flaws. The two spikes in Apple work appear to be related to Safari releases (though the first also correlates with the release of Chrome and appear to be a lot of work on the JavaScriptCore JavaScript engine).

I'd also at some point like to take a look at which projects attract which developers. As I looked at this data I noticed in particular that SVG and the inspector seem to have attracted, better than other parts of WebKit, developers outside of any particular community. I suspect it is because those pieces of WebKit are relatively self-contained; stuff like the core layout engine are way more difficult to hack on (unless your last name is Hyatt). If you'd like to play with the data I've collected (or improve it!) the code is up on github.

Extensions paper

2010-01-28T17:43:1264700580Z

A paper on the security features of the Chrome extensions system, drawing on the experience of Firefox.

Aaron's thoughts.

Free fonts

2010-01-15T02:41:1263523260Z

Many people were upset that our tests depend on the non-free Microsoft web fonts. However, realistically, many web sites depend on these fonts and it is important that we test that our font metrics match the metrics used on those sites.

Separately, someone filed a bug saying we're using the wrong font on ubuntuforums.org, a popular forum site. I took a look and found their CSS says:

font-family: Verdana, Arial, Tahoma;

with no mention of their presumed intent that you fall back on a free sans-serif font if those fonts aren't available. So Chrome just falls back to the default font: a serifed one. (The interaction between CSS font fallback and fontconfig is complicated and ugly; hopefully I'll get to it another time.)

In conclusion, now I have a great example of the point I was making about non-free fonts.

TotalFinder tabs

2010-01-12T16:50:1263315000Z

The TotalFinder project's recent release includes Chrome-style tabs, taken directly from the Chrome tree. I think this is the first project I've heard of that isn't directly browser related that has used code from Chrome.

Here's the relevant section of that page, just in case it changes in the future:

I had an idea of bringing tabs experience into Finder back in November 2009. Obviously this is a hard task, but so exciting. Iâ€™m quite new to Cocoa and Iâ€™ve never implemented such a complex UI element in Cocoa before. But Iâ€™m not afraid to search the internet and get deep into problems I happen to be exploring.
Luckily enough, there is a great state-of-the-art open source tabs implementation in the Chromium project available. Iâ€™ve studied briefly their codebase and it looked as a promising path to follow. I took their main browser window implementation and also components realizing tabs and extracted them from the main project. Iâ€™ve spent few days stripping dependencies and isolating functionality I needed. Dirty job but it paid off. After few evenings Iâ€™ve got working skeleton app with blank tabs.
Iâ€™d like to thank Google to made this all possible. I was really surprised how clean and well-documented the Chrome code is. People working on it earned my full respect. Kudos guys!

The story of Iron

2009-12-30T18:15:1262196900Z

Iron claims to be a "privacy-oriented" fork of Chrome, which removes a bunch of pieces that the Iron author claims are privacy invasive. In the abstract this is a thing I'd support -- nothing like some publicity to put pressure on the project to be more careful about user privacy -- but when you look at the details it kinda falls down.

Right when we first came out our IRC channel was flooded with hundreds of curious people, and for posterity's sake I logged it. (It's now logged by a third party.) It turns out the log of September 19, 2008 is interesting to look back on. That link is to the unmodified file that my IRC client produced, but since you're unlikely to want to read through it all (search for "Iron" if you'd like), I'll summarize the interesting bits.

(For context, I am "evmar" in that log, and the usernames with a + before their names are Chrome developers.)

Someone with the nick of "Iron" joins the channel and announces they're making a fork of Chrome.
They ask some semi-legal questions about how to advertise it, which we can't answer.
They ask some technical questions, like how to change the name of the browser that shows up in the executable, which kuchhal nicely helps them with.

Then there's this exchange (reformatted to remove timestamps and add line wrapping):

<Kmos> Iron: why not contribute to it, instead of forking ?
<Iron> because i removed all privacy-related code
<Iron> e.g. RLZ
<Iron> and URL tracking every 5 seconds after start
<Iron> the original chrome  is heavily communitating to google...i
       hate that
<jamessan> all of those are supposed to have options to disable them,
           iirc
<Iron> yes but they haven't options yet
<Iron> and nobody knows when the next beta is released
<jamessan> so work on getting the options added so they'll be there
           for the next release
<mgreenblatt> Iron.. why not propose a patch based on preprocessor
              defines that disables the sections you dislike without
              forking the code?
<mgreenblatt> (assuming such a thing doesn't already exist)
<Iron> because a fork will bring a lot of publicity to my person and
       my homepage
<Iron> that means: a lot of money too ;)
<Kmos> rotflol
<Iron> what means rotful?
<mgreenblatt> Iron.. you're a large corporation that can dedicate the
              time to support a fork of something as complicated as
              chromium?
<Kmos> Iron: google about it
<Iron> yes there is enough time to support it
<jamessan> heh, you're expecting to make lots of money from making a
           fork of chromium? that's quite amusing
<Iron> i dont take money for my fork
<Iron> but i have adsense on my page ;)
<Iron> a lot of visitor -> a lot of clicka > a lot of money ;)
<Kmos> and do you think google should support your fork
<Kmos> lol
<mgreenblatt> Iron.. it's always good to have dreams ;-)
<Iron> we are here in germany
<Iron> the press will love my fork
<Iron> i talked to much journalists already
<DrPizza> Why are you forking?
<DrPizza> to do what?
<Iron> to remove all things in source talking to google ;)
<jamessan> to get fame and fortune
<Iron> nobody here trusts google
<Iron> the german people say: google is very evil
<jamessan> yet you use google's adsense

Then follows a bunch of "Google is evil" conversation which you've heard before. (And a rather strongly-worded flame from DannyB about the above, which I'll skip for brevity.) This sort of non-technical discussion is frowned upon in our development channel, so he's then more or less told to go away (surprisingly politely, in retrospect).

(Now, it's possible (but highly unlikely) this isn't the eventual author of Iron, but in some sense that's irrelevant to the two meta-points: (1) if you don't trust Google to not do something sneaky, you probably shouldn't be running software made by Google, and (2) why would you trust code from some random third party more?)

Furthermore, the "URL tracking" mentioned both on IRC and on the Iron website refers to the GoogleURLTracker class. This unforutnately-named class figures out whether to use google.com or google.es for searches from the URL bar, and does not in any way do any sort of spyware URL monitoring. This is obvious to anyone who can read code, and should be obvious to anyone technical enough to produce a product like Iron. At this point I can't believe they're doing anything other than being intentionally misleading.

The header plainly says as much, and also:

// To protect users' privacy and reduce server load, no updates
// will be performed (ever) unless at least one consumer registers
// interest by calling RequestServerCheck().

Which, you can easily verify, is only ever called if you're using Google as your default search engine, which Chrome doesn't even use by default (Chrome asks you what search engine to use the first time you install).

This serves as a good example of the sort or significant effort we've put in to make Chrome be privacy-conscious and Google-independent. Half of the bullet points on the Iron "feature" page are options that can be turned off in a clearly-marked "Privacy" section of the Chrome options, and the other half are misunderstandings like this one.

(Edit: I am biased here towards Linux Chrome; Windows Chrome does not make it obvious how to remove the updater nor RLZ. I will hopefully find time to post about those some other time.)

So where does that leave users? I think there is a space for a privacy-conscious browser: a "portable" one that starts in Incognito mode, that integrates Tor or some other proxying system, one that defaults some features that trade privacy for convenience off -- but I am highly skeptical the Iron developer is the person able to produce such a thing. In fact, I think that browser could be Chrome, if someone would contribute patches for it (there's an incognito-at-startup flag already, I believe) instead of needlessly forking for shady reasons.

(Edit: It is negligent for me not to point out the reportedly excellent Torbutton extension for Firefox, which is probably your current best bet in this space.)

Flash LAHF workaround

2009-12-08T22:53:1260312780Z

Flash uses an instruction not available on some CPUs, causing it to die with SIGILL ("Illegal instruction"). Some might say, "Ok, let's wait for Adobe to release a fix." But not Maks Verver, who wrote this bad ass patch:

/* Simple work-around for running the 64-bit Adobe Flash plug-in version 10
   on Athlon64 processors without support for the lahf instruction.

Compile with:
cc -fPIC -shared -nostdlib -lc -oflashplugin-lahf-fix.so flashplugin-lahf-fix.c
Then place the .so file in the plug-in directory (e.g. $HOME/.mozilla/plugins)
or use LD_PRELOAD to force Firefox to load the library.

   - Maks Verver <maksverver@geocities.com> July 2009 */

#define _GNU_SOURCE
#include <stdlib.h>
#include <signal.h>
#include <ucontext.h>

static void sig_handler(int signal, siginfo_t *info, void *context) {
        if (signal != SIGILL) return;
        if (*(char*)info->si_addr != (char)0x9f) abort();
        greg_t *regs = ((ucontext_t*)context)->uc_mcontext.gregs;
        ((char*)&regs[REG_RAX])[1] = ((char*)&regs[REG_EFL])[0];
        regs[REG_RIP]++;
}

static struct sigaction old_sa, new_sa = {
        .sa_flags     = SA_SIGINFO,
        .sa_sigaction = &sig_handler };

int _init() { sigaction(SIGILL, &new_sa, &old_sa); return 0; }
int _fini() { sigaction(SIGILL, &old_sa, &new_sa); return 0; }

It catches the signal, inspects the registers, and by hand updates the state and advances the instruction pointer.

Forking upstream software

2009-12-03T17:09:1259860140Z

Tom wrote a rant about the way we've incorporated other free software, and while I know it's easy to get carried away when you're mid-rant and talk in generalities, I thought it'd be interesting to look at the details.

First, some background. On Windows, your software is basically on its own: if the code you want isn't provided by Microsoft, it's your responsibility to package, ship, and update it. So for any third-party libraries we use (take sqlite as an example) we already must dedicate resources to integrating it into our build system, tracking security vulnerabilities upstream, and updating the code we use. This cost is fundamental to the endeavor, and any approach to software management beyond that (notably the Linux way) is by definition extra work to support. (That doesn't mean I don't want to change things, but just that doing so doesn't come for free.)

An interesting side effect of having all this code locally is that there is no longer a difference between your bugs and someone else's bugs: in tracking a bug down, you trace the code to the source of the problem and then you fix the bug, regardless of whose it is. Contrast this with development of software on any other platform, including Linux, where if there's a bug in Karmic's version of GTK the best we can say is "darn, let's file a bug upstream then attempt to find a workaround". (Which is what we've done; for a particular example I'll note my coworker Dan has written patches for two or three window managers, not that that helps any of our existing users.)

I believe this is generally the approach we have taken: do whatever it takes to make the best product we can, contribute bits upstream where we can. So let's take a stroll through the READMEs in the third_party directories and see what we can find. As I type this post I don't actually know the conclusion I'll reach, so this is for my education as much as yours. (Edit: Now that I've gone through more of this, I'll use the short phrase "build changes" to mean "changes made to let this to build as part of our cross-platform build system, ending up as a static lib that gets pulled into our final binary.")

apple: two random files, no README. I have no idea what this is. The reviewer should have caught this before checking it in. Filed bug 29334. (Edit: now fixed.)
bsdiff: "This is Chrome's locally patched copy of Colin Percival's bsdiff tool [...] obtained from Mozilla's local copy/fork of bsdiff." The entirety of the code is a 382 line source file, so I can't be too bothered either way. Fork severity: harmless.
bspatch: just like bsdiff. 357 lines.
bzip2: "When updating, no modifications should be necessary aside from copying the subset of files included here."
cld: I believe this is an internal Google project. I wonder if was ever officially open sourced. Filed bug 29342 about unclear license.
codesighs: "There are no local changes to the code itself."
expat: Removed unused files. Two patches: one to fix a compiler warning on Windows, one to fix a crash. The README says it's version 2.7.0, but as far as I can tell from the home page and my Karmic install the latest version is 2.0.1 released in 2007? Perhaps it's a typo in the README. I tried to check if we'd reported the bug into their bug tracker but I get a server error when I click their bug tracker link. Fork severity: suspicious.
ffmpeg: Patched to hell. I believe we actually build this with gcc on Windows, it is so gnarly to build. The README is terrifying to me; it says we patch out some of its hand-written assembly so our crash catcher can function. Fork severity: fail.
On the other hand, I don't think ffmpeg really cares too much; it seems from their download page they don't actually make releases, and instead recommend just pulling their trunk.
I asked a coworker about it and he said:
The good news is that of the 50 patches about 1/2 actually have made it upstream in one way or another (mostly by the FFMpeg devs themselves). I've been tracking it on a spreadsheet [...]
Why so many patches? I think a lot are from our security guys who found a lot of bugs after spending some time fuzzing it.
fuzzymatch: A one-off C program agl hacked up.
glew: OpenGL stuff I don't quite understand. The local modification was for sandboxing reasons, but it is pretty invasive (much of the API now goes through an extra indirection) so it seems unlikely upstream would want it. Fork score: not good, but I think it's legit.
harfbuzz: I know this one because I work with it personally. We track upstream's git repo directly and have contributed both bug fixes and a bunch of code in upstream's "contrib/" directory. The last time I sent patches Behdad said something to the effect of: "you're basically the only people using this code so don't worry about it too much". I hope to retarget Chrome to the harfbuzz-ng rewrite this month.
hunspell: A variety of small patches for integrating it into the build (of the "remove reference to "config.h" sort), "Change the input params of the constructors to receive a FILE* instead of a file path. This is required to use hunspell in the sandbox." Diffstat: 6 files changed, 28 insertions(+), 25 deletions(-).
Additional major change: a different on-disk representation for a large memory and CPU performance impact. I asked the author of the Chrome patch and he said:
There's not really a mailing list or active project site as far as I could find. I emailed some random guy whose email address I found with some of my perf numbers and he responded with "oh thanks" but that's the extent of the communication.
icu: See bug 28294, "use system ICU". The version of ICU we need is newer than the one provided on OS X or on Karmic (let alone Hardy, which we also want to support); we also continue to make improvements. We send these patches upstream.
jemalloc: Diffstat: 5 files changed, 38 insertions(+), 17 deletions(-). The local changes there aren't even up to snuff for acceptable Chrome changes, with commented-out bits. I don't believe we actually use this yet, but Mike has been experimenting with it. Fork severity: eh.
lcov: Upstream + a perl script. I think this is only used by the build bots.
libevent: Upstream + build system change. We carried a forked version of this for quite a while, due to a bug that caused libevent to use a large amount of extra memory per instance (ChangeLog says: "Saves up to 512K per epoll-based event_base."). We sent that patch upstream but it took a while for Niels to make a release carrying it. Upstream ChangeLog includes patches from multiple Chrome people (Dean and Adam).
libjingle: Lots of local patches. I ran into Sean (the author) the other day and he indicated libjingle is more or less unmaintained, but don't quote me on that. I see no attempt to upstream these patches; but I do see at least two unanswered bugs on the bug tracker with patches from Craig (one of the Chromium contributors).
libjpeg: Upstream version + fixes to integrate into our build.
libpng: Same as libjpeg.
libxml: Lots of changes! The README indicates we cherry-picked unreleased security fixes on top of the latest released version, but the version we carry is now older than trunk. Diffstat: 9 files changed, 310 insertions(+), 9 deletions(-). Majority of the diffs look like they're adding ICU support; I tried to see whether upstream supported this but in my ten seconds of looking I found this dispiriting old thread. (Edit: originally I wrote that upstream was opposed to supporting ICU; I see now I failed to read the context correctly, and that they welcomed an ICU patch and that the following quote that I used in the original post was about why upstream would prefer people to not ICU, not that they were completely opposed to it.)
Mark> I'm not advocating that ICU be the default, I'm just curious why you feel vendors should not use it if it is present.
Daniel (upstream)> Very simple, I don't want to be perceived as depending on ICU.
Ironically, the person involved in that thread is none other than Mark Rowe, who I now know as one of the WebKit hackers. Maybe things have changed since 2007? Fork score: not sure. Even if upstream does allow a compile-time dependency on ICU, I doubt any distros would ship it that way. And we lose points for having other patches.
libxslt: Build changes, one functional change for Windows. Unclear if that's upstream or not, nor why it's necessary in the first place ("Modified libxslt/security.c to use GetFileAttributesA instead of GetFileAttributes.") -- perhaps for the sandbox?
lighttpd: Used for running HTTP-based tests. Just Mac/Win binaries. We historically only pull binaries if you're on the relevant platform; the fact I have this on my Linux box was probably an oversight.
lzma_sdk: README indicates only build changes.
modp_64: 913 lines of code. Build changes, including some that make it reach deep into shared Chrome headers. I am suspicious but it's also tiny.
mozilla: Mozilla headers needed to work with Java. Build changes.
npapi: Headers needed to work with Netscape plugins. Build changes. Rather forked. I don't think this is available as a standalone library, though.
ocmock: No modifications.
openmax: I don't know what this is. khronos.org reference makes me think WebGL or something. The README says it's headers.
ots: Written by the Chrome team, trying to be a library other browsers can use.
protobuf2: Written by Google.
pyftpdlib: A server used for testing FTP. Local patch is to remove a timing-based DoS protection, because the tests want to run as quickly as possible and so they hammer on it. Maybe this should be made into API and upstreamed?
pywebsocket: Written by the Chrome team, trying to be a library other browsers can use. WebKit uses it now I think.
scons: Build changes. But don't use scons anymore; we should probably drop this.
simplejson: Build changes.
skia: Written by Google. We push patches into it.
sqlite: Forked heavily. The full-text indexing support for SQLite (which is now upstream) was written by someone on the Chrome team, and so he feels comfortable making whatever changes needed. Fork severity: bad. Someone needs to spend some time cleaning this up.
Concidentally, someone left an anonymous comment on Tom's post ranting about sqlite upstream, saying why they forked it as well; but I don't think this has been our experience at all; I met Richard once at a conference and he seemed like an ideal upstream -- friendly and fixated on details.
tcmalloc: Written by Google. I think there is a lot of experimentation going on here, so it's probably forked a bit.
tlslite: Used by tests. Includes a patch with bug fix, which references a thread on the user mailing list where someone else ran into the same problem. It's unclear if the patch has been upstreamed. Fork severity: not good.
WebKit: WebKit is a full half of the project's code weight, and we have made extensive changes to it. We now have many people on the project contributing to upstream WebKit and we now can build directly out of a copy of upstream's trunk with no local patches. More on upstreaming to WebKit in another post.
xdg-utils: We contributed xdg-settings upstream, then pulled it back down into our tree. For the other xdg utilities we already use the one already on the system. It is not clear what the current relationship is between our copy and the upstream release; on the other hand, since we wrote the only file we use, it is unlikely anyone else needs it. Fork score: not so good. Filed bug 29769.
yasm: gnarly. Needed for ffmpeg. See ffmpeg above.
zlib: Fix a compile warning. Windows fixes. Not clear whether the changes are upstream.

There are a few other directories other than the top level for third-party code. Let's now go into them alphabetically:

base/third_party/dmg_fp: As far as I can tell every project that has ever used this has forked it.
base/third_party/icu: Some basic UTF handling functions pulled from ICU (used for bits of code that don't want to depend on all of ICU).
base/third_party/nspr: This is just a couple of files, not all of nspr. The README is unclear. Filed bug 29764.
base/third_party/purify: The Windows equivalent of Valgrind. But there is no README. Looks like headers. Filed bug 29765.
base/third_party/valgrind: Header for working with Valgrind. It seems a little excessive to depend on a 24mb Valgrind package to build with this one file.
base/third_party/xdg_mime: Claims it contains one minor compilation fix, looks like working around a warning.
base/third_party/xdg_user_dirs: Build changes. Upstream designed this with the intent it is always copied into other projects, never built as a separate library.
chrome/third_party/jstemplate: Minor changes. There's not really a good build/packaging infrastructure for JavaScript libraries anyway, so this is hand-"optimized" (removed dead code, run through the Closure compiler).
chrome/third_party/wtl: Windows code. "These headers are almost the equivalent of WTL 8.0 from http://sourceforge.net/projects/wtl/ with patch #1871358 applied."
net/third_party/nss: libssl from upstream. Used for staging various SSL changes for e.g. SPDY experiments; those changes eventually show up upstream. The NSS maintainer works on the Chrome team, and he ok'd this.
net/third_party/parseftp: Copied from Mozilla. Just build changes (remove NSPR, add namespace). I believe Pawel is working on this with Mozilla, but I don't follow this stuff closely.

...*whew*, that was exhausting! And I am actually rather surprised -- I expected to find more projects hacked up like sqlite, when in fact that's one of the few projects we've actually forked in a meaningful way.