Gmail in Chromium "Test Shell" on Linux

The other three guys in my office all work on Chromium for Linux. Right now, they are working on bringing up the "test shell". The test shell is a very simple browser that the Chromium development team uses for testing our integration with WebKit. It is the first step of porting Chromium to a new platform.

Today, one of the linux guys sent a message from Gmail in the linux test shell for the first time:

From: "Dan Kegel" 
To: chromium-dev@googlegroups.com
Subject: sent from test shell on Linux!

Dude, gmail works in the test shell on Linux!

The team is still a long ways from even getting the web to render correctly, let alone building the real browser UI. But it's exciting to see things falling a little more into place each day.

New work blog

This is my new blog about work stuff. Cat pictures and vacation stories can be found over yonder.

Greasemonkey in Chromium

Evan and I have been hacking on Greasemonkey support for Chromium in our 20% time. It's been fun. Actually, it was Evan who started the work... after months of pestering me, he got frustrated and started hacking.

Implementation is more interesting than in Firefox because of Chromium's sandbox. The renderer processes are where scripts must be executed, but the renderers are not allowed to read the scripts from disk. So we set it up so that the privileged "browser" process reads the scripts into shared memory and broadcasts them to the renderers. It also watches for changes on disk and rebroadcasts when changes occur.

Note that like everything else in Chromium nightlies, Greasemonkey support is considered experimental and may change, break, or disappear from build to build. That said, this is something a lot of us on Chromium are excited about, and look forward to continuing to improve.

WorkerPool destruction cleanup done, now on to actual features

The main things that I have volunteered to do for the next Gears milestone are:

• Implement better error-handling support for WorkerPools
• Make the onmessage callback optional

I'm diving into the first of these two today. The first thing to do is figure out how to throw errors in each of the JavaScript engines globally. That is, if an error occurs in a WorkerPool and isn't handled by WorkerPool.onerror, then the error should be thrown in the global context of the parent page. Basically, it should do the same thing as what happens when you run this JavaScript code:

window.setTimeout("throw new Error('boo!')", 100);

Spidermonkey (the JavaScript engine inside Firefox) has an API that I believe we can use for this purpose: JS_ReportError. I'm not sure if there is an equivalent for IE, or if I will have to basically do something like: eval("throw new Error('boo!')"). I would like to avoid using eval if possible because it seems hacky and there are more security considerations.

Gearpad improvements for high-latency connections

I made some changes to Gearpad to make it work better on high-latency connections, like the one I use on my daily commute.

The problem was in my implementation of optimistic concurrency. This is what I used to store on the server for each note:

• Id
• Version
• Content
  

At client startup, Gearpad fetches the current content and version of the note from the server. Then, when an edit occurs, it sends the version it has, plus the new content to the server. The server checks to see that the version sent matches the one that it has. If it does, it makes the edit, increments the version atomically, and returns the new content to the client. If the versions don't match, then a different client must have updated the note and this is a conflict. Right?

Wrong. What happens if an edit occurs before a previous edit from the same client returns? Here are a couple options:

• Wait for the first edit to return, then send the second edit. This will make things much slower, and more complex since the editor state and server state start diverging more and more when the user is faster than the connection to the server.
  
  
• Cancel the first edit and send the second one. This is what Gearpad does. But this means that sometimes the server gets the update and increments the version, but the new version doesn't make it back to the client. Then the second edit is sent and the server things a conflict has occurred.

Solution: the server needs to also store the last client that talked to it. It's only a conflict if the version is out of date *and* the update is from a new client. New server schema:

• Id
• Version
• Content
• LastClientId
• NextClientId
  

This change also involved migrating Gears database schemas, which can be tricky. I'll talk about that next time.