I became a Mozillian 10 years ago when I started participating in Bugzilla and helping with the Spread Firefox campaign, earning both the 25 million and 50 million-downloads coins. I was just a freshman at the University of Illinois studying Computer Science, but I was eager to help the non-profit Mozilla create a web browser that promotes user choice for liberty.

San Francisco Mozilla Monument

Mozilla’s founders created the mission for openness, innovation and opportunity on the Internet; and because of that, I was able to find my passion of helping people. In between lectures, I hacked on open source Firefox to create the AwesomeBar through many iterations of conversing with individuals to learn about their specific needs. I collaborated with other Mozillians to come up with ideas and to implement them into this Firefox feature which still provides better and faster choices for everyone.

Yesterday, I cried when I learned that one of Mozilla’s co-founders was leaving [brendaneich.com]. It was the most I’ve cried since my mother passed away, and in some sense it was appropriate as Brendan is a “founding father” of the organization I’ve dedicated over a third of my life to.

Even as Brendan announced his departure, he provided next steps to advancing the mission by reaffirming Mozilla’s focus on users. The direction he provided could put the non-profit Mozilla as a users union leader to push back the bullying aspects of the Internet that prey on individuals (think of privacy policies or terms of services) and instead flip that around to be pro-user [blog.mozilla.org].

I’m a Mozillian because the founders made Mozilla with the mission. I believed in the mission when I became a Mozillian, and I still believe in it now — especially with this golden opportunity for Mozilla to fight for users. I hope all Mozillians can continue to collaborate together to make the world a better place for everyone.

– Ed Lee

For my first week working remotely from Champaign, I focused mostly on the About:Tab sprint, but I got in some time for other Labs projects like Weave and the Design Challenge.

I’ve already written about the About:Tab initial prototype release that provides a streamlined new tab page that needs no configuration, so I’ll mention specifically what I worked on: frecency site listing, thumbnails, feeds, and predicting behavior.

About:Tab Sites

The site listing was the easiest part as I’ve already had plenty of experience with the Places database with the Location Bar for Firefox 3 and Auto Dial. The query I used is actually quite different from the existing queries as it focuses on finding top pages of sites instead of just any top-frecency pages. At one point I was tempted to also show related pages of that site similar to EdBrowser’s Site Launcher, but Beltzner set us back on track of quickly creating a prototype. 😉

For those using About:Tab, you might have noticed you can drag the sites around, but that doesn’t actually do anything. (Actually, it’s useful for preparing screenshots..) I used jQuery UI’s Sortable [jqueryui.com] to let things get dragged around. This was actually the first time I used a framework like jQuery, so I had to do a lot of digging around the API Documentation [docs.jquery.com]. So if you look through the mercurial code repository [hg.mozilla.org], you’ll see plenty of chained $()s.

About:Tab Thumbnails

I had some trouble coding up the thumbnails as I kept thinking about how to efficiently grab thumbs and save them, but then I realized it was just a prototype, so for now it just loads the thumbnails once and saves them in memory for the session. This turns out to work pretty well as the site listing doesn’t change much and the thumbnails are just there to help remind you “yes, this is the site I want” as after a while, it should be muscle memory for going to site you want.

Testing grayscale filters on cake!

I also got to play around with SVG to make the thumbnails gray until hovered. I found roc’s post on applying SVG effects to HTML [weblogs.mozillazine.org] and quickly put together my own example. I had some troubles getting it to work in about:tab because the about: protocol doesn’t support #fragments, but because we clear out the location bar anyway, I decided to switch the page to just use the chrome:// URI.

About:Tab Feeds

A lot of the heavy lifting of automatically finding and tracking feeds was straight from Atul’s Ambient News [toolness.com]. The main part I worked on was grabbing feeds for just the corresponding sites shown instead of showing any feed from top sites. Here I used an asynchronous SQLite query to get the feed data, so that’s part of the reason why feeds slowly fade in after opening a new tab.

About:Tab Predicting Behavior

There already is some behavior predicting in the prototype like suggesting undo closed tab and searching for addresses, but I’m actually working on something separate.. predicting where you would want to go next based on where you’ve already been. The Places backend already remembers your history to help decide which pages to show in the Location Bar, so mining useful data like starting pages is totally possible.

This functionality isn’t in the initial prototype, but I’ve got some results that seem promising.. at least for my own browsing history, so we’ll figure out a way to show this information to the user. The ability for Firefox to accurately provide useful pages is pretty neat but kinda creepy at the same time..

For example, after searching for “weather champaign,” it would suggest the GPS-tracking bus results. Or after going to Air Mozilla [air.mozilla.com], it knows that I open up the Weekly Status Updates [wiki.mozilla.com]. Or when I go to one news site, I frequently go to other news sites.

Weave & Design Challenge

For Weave, I’ve got a number of patches in the pipeline for Milestone 5 such as being able to “start over” as well as automatically disabling Weave while offline and in private browsing. Other simple patches have already landed like clearing failed login notifications after a successful login as well as allowing right-clicks on the Weave statusbar icon.

In terms of the Design Challenge [labs.mozilla.com], I figured that while I’m working remotely in Champaign, it would be good for me to reach out to the University of Illinois’ HCI group. So I’ll be talking with some of my former professors like Karrie Karahalios [social.cs.uiuc.edu] who focuses on social computing.

I’m now a full-time software developer in Mozilla Labs working primarily on Weave [labs.mozilla.com]. I suppose that means I’ll have to pay income taxes again.. 😉 but that’s insignificant compared to helping Weave redefine web clients where users can interact with websites and friends in whole new ways. I’ll have less time to write about the EdBrowser, but being in Labs, I might get to build some of this as a bunch of ideas for that web client was built around Weave. 🙂

Most of what I worked on during the week was getting familiar with the Weave codebase and some initial debugging/hacking. I also did a little bit on optimizing the Location Bar for Firefox 3.1+.

Is 4 > 20? Yes! ?

My first task was figuring out why 4 is larger than 20 [bugzilla.mozilla.org]. This was causing problems with Weave history sync on Fennec when we set the Places sorting mode to get a number of recent pages. So to try figuring out what went wrong, I started with my Unibody Macbook and installed VMWare Fusion [vmware.com] to run Ubuntu 8.10 [ubuntu.com] for a cross-compiling scratchbox [wiki.mozilla.org] to build Fennec [wiki.mozilla.org] for the Nokia N810. (Side note: don’t run hg from the scratchbox. It’s old. Like 0.9.1 old.)

That’s just to build Fennec. Getting it to run on the Nokia N810 is just as fun. The default package is bzipped, but that doesn’t work on the device by default, so I have to repackage it as gzip. Even before then, you’ll need to jump through hoops to get Fennec onto the device, but the easiest way seems to be putting stuff on a web server and downloading it wirelessly to the device.

Long story short, I used my x86 asm experience from doing computer architecture/compiler research at UIUC, and noticed the compiled code for SetSortingMode [hg.mozilla.org] was doing a plain comparison of the input argument to the value 20.

cmp r1, #20

While the value 4 was getting passed into the unsigned short argument, the compiler was expecting a 4-byte sign extended value. Vlad gave me a quick patch that made the XPTCall magic handle smaller-than-4-byte types correctly, and all was good. 4 is now less than 20.

Initial Weave Hacking

I got a Weave account and used it for the first time. (And so can you!) [services.mozilla.org] I kept track of various small UI issues as I used the Firefox client and pushed fixes for them — small localized changes are a great way to get into the bigger project. But I eventually messed up my account by typing different passphrases from different computers.

Lucky for me, I’m working on a way for users to reset the data on their client/server [bugzilla.mozilla.org]. The general idea here is to allow the user to “start over” incase something went wrong. 1) Clean sync with the server, 2) Restart the client from server state, 3) Make other clients like the current one, 4) Have clients repopulate the server.

Before I dove too deep into coding, I got a whole look at the Weave architecture to better understand what pieces od what: A bird’s-eye view [toolness.com] and Client APIs [wiki.mozilla.org]. Also, Weave is written with a pattern called Trampolining Generators [neilmix.com]. This basically lets you use asynchronous calls synchronously and get something more like traditional threading.

Color-coded log files for easier tracking of Weave behavior

I also figured I would be looking at debug logs a bunch, so I decided to spice up the plain black/white log file [bugzilla.mozilla.org] and color code the text by the type of message (warning, info, debug, etc.) and the background by the component generating the message. Hopefully now I’ll be able to get deep into Weave hacking.

AwesomeBar Speedup

I posted about speeding up the location bar, and it’s made it into Firefox 3.2 already. On the way there, I used Andrew Sutherland’s SQLite explain parser to better understand why things were slower and faster. Basically, a query becomes a set of opcodes like how javascript code becomes an intermediate bytecode, and the engine executes this stream of instructions.

Andrew first made this tool to analyze his own query optimizations [visophyte.org], and now he’s made the code available for everyone to use and contribute [hg.mozilla.org]. Thanks!

Perhaps being stressed out and tired and after having some drinks isn’t the best time to write blog posts, but this is something I’ve been thinking about over the last few days. And I suppose in other conditions, I definitely wouldn’t be as open about this as I probably will be. I’m not accustomed to talking about personal things in person and especially not blogs. I tend to focus on objective things that “gets things done.”

So why did I work on Firefox?

Maybe I like to help people. Maybe I just like making things better when I see a problem that I can fix. Maybe I just want the world to be a better place. Or maybe I just like to work long hours. I do all this even if I don’t get much out of it. I suppose good thing about Firefox is that it’s open source and anybody can contribute and there are many people to help.

I recently sent Gerv an after-summer-of-code update and only then realized how much I’ve worked on. How much I wanted to help those people have a better experience. How many problems I saw that I could fix.

Both the download manager and location bar were being changed for the better, but there was so much more work to be done. Just to list a few things, I’ve added better download manager functionality with cross session resumable downloads, auto-pause/resume on sleep/wake, auto-resume on browser restart/crash, various fixes for saving files and some download status bar work.

Additionally, there’s the redesigned download manager UI work with the full listing of downloads and the ability to do multi-word search against any text shown in the list, and providing a way to display download progress / speed / times consistently as well some localization support for plural forms.

And of course there’s the work to make the location bar awesome. I wasn’t happy with the location bar return seemingly random results, so I decided to make things better. I started with the adaptive learning, but along the way I added in multi-word searching across urls, titles, and tags as well as word boundary matching. I also pushed patches for emphasizing all matches and cleaning up the display to be more compact as well as correct for foreign characters. There are also performance fixes to make results come back faster and render with less work.

Unfortunately, there were costs in making things better for everyone else. I haven’t been concentrating on my coursework, and my assignments have been partially completed when I turned them in. I’ve been tired and feeling burned out.

Just last week, I easily spent over 100 hours on Firefox stuff for my 1-week spring break. I wasn’t catching up on my assignment that was due the week before. Why not? There are still many things that I feel should be fixed.

I suppose I finally couldn’t take the stress from keeping things in, so I talked / cried / discussed with my Ph.D. advisor about things. He has been very good to me even though I haven’t focused as much on my research as I should have. Especially that he’s paying for my research assistantship and my tuition waiver. So I suppose unofficially, all my work on the Download Manager and the AwesomeBar has been funded by my advisor. (Apparently the download manager, location bar, and download manager again are the top 3 favorite features of Firefox 3 at mozillalinks, so I hopefully his money didn’t go to too much waste.)

But just working long hours isn’t really that bad. And I never really minded before, so I guess there must be something else.

It might be related to the improportionate amount of effort that I put in and what comes out. For those who followed the adaptive learning work to make the location bar into AwesomeBar, you might have noticed the code was pretty much ready when I first wrote about it in my blog early November. It wasn’t until a quarter of a year later (and almost 20 versions of the patch — mostly unbitrotting) that the patch got the appropriate bits twiddled so that it was high enough on the priority list to be reviewed and make it into Firefox 3.

I don’t think I did anything wrong in the process. I followed the rules and even provided extensive testcases. Perhaps there’s an issue with the code / review / approval path? For some reason, it just seems strange to me that only after people have done all the work writing the code, creating testcases, and getting reviewed does a final approval decision say yes or no.

It might also be that I try to fix too many things at once. I tend to have 10-20 patches on my mercurial queue stack, and the bases keep changing as things eventually get reviewed and modified. Maybe I’m creating artificial work unbitrotting myself, but that needs to be done when certain patches are deemed to be more important and I need to pull it from one end of my stack to the other.. Conflicts galore.

I realize it’s time to ship and changes need to cut back, so the process will have more hoops to jump through. But maybe I wasn’t expecting so many.

I still have a number of patches ready that add some neat things to the AwesomeBar such as being able to restrict searches to history or bookmarks and forcing matches against the url/title (additionally, you can set it up to force your queries to match against the url by default or only search non-bookmarked items). There’s also showing keyword queries and searching for strings as well as ignoring the protocol (e.g., “h” doesn’t match Http). Of course there’s tweaks to the adaptive learning to make it even better. But I suppose those will likely get to Firefox Next.

But back to unexpected hoops and tightening of the review process.. Earlier today, I was trying to make it easier to write download manager *test* code by adding a notification, and it was a very simple change to the download manager code. I simplified and cleaned up one of the testcases, but apparently it’s not good enough to review without at least 10 more testcases.

Also, I was trying to add in support for multiple-selection in the download manager so you can easily select multiple downloads to delete, pause/resume, etc. I even had a testcase locally that makes sure only selected items were deleted, but apparently the minimum number of things to test would be at least 20 more testcases.

But it’s getting late, and I suppose I’m feeling better already.. a little. Perhaps enough to even stick in an emotion 😉 . Maybe I’ll feel good enough by the morning to finally post about the new awesomeness of the AwesomeBar for Beta 5.. definitely with more pictures too. 🙂