Shawn Wilsher

So, I realized today that I’ve been neglecting my umich e-mail, and consequently any and all Facebook alerts. I haven’t been checking Facebook for a while now unless I got an e-mail. It looks like I stopped paying attention to that lovely e-mail account around 5/9. Yeah…that’s a lot of e-mails I have to process now, which I’m going to start on tonight. Sorry to all those who sent me anything in that time - I’ll get back to you real soon!

[I use a Mac, so all the images in this post are of the Mac user interface. The UI for other platforms will differ slightly. Click on pictures to view other sizes.]

Firefox 3 brings a brand new download manager to the scene. There were lots of issues that existed with the old download manager both in terms of the UI and in the code that made it work. So for Firefox 3, we redid the whole thing to provide a better experience all around. It’s one of my favorite features in Firefox 3, but then I’m a bit biased. This post discusses the new features of the UI.

Old Meets New - a UI Comparison

The Firefox 2 download manager (above) would display the download’s icon (but not on Linux), its name, its status, and two text links to open and remove the download. In contrast, the Firefox 3 download manager (below) displays the download’s icon (even on Linux now), it’s name, the time of the download, the download size, and where it was downloaded from. For an active download, the size of the download changes to the amount downloaded so far. The main goal was to provide more useful information to the user.

You might notice, however, that there is now primary UI to open or remove the download. The idea here was to provide a less cluttered UI. However, just like before with Firefox 2, you can open your download by selecting it and pressing enter, double clicking it, or selecting open from the context menu. In fact, the context menu has grown a lot too!

The middle two options provide functionality that was once available from the old properties dialog. That dialog was removed because it was out of place. One of the new features of the new download manager is the ability to select more than one download (as hinted to by the “Select All” entry in the context menu). You can select multiple downloads (below) to perform an action on them such as remove, pause, or resume.

Searching

The new download manager also adds the ability to search through your download history. Let’s say that you recently downloaded a bunch of pdf documentation from threadingbuildingblocks.org and want to open it. The folder where all your downloads go is hopelessly cluttered, so you open up the download manager, and search for “pdf threading”. In a matter of moments, you are presented with the documents you wanted so you can now open them, or if they were deleted, you can re-download them.

Status Bar Indication

Perhaps the most useful feature that has been added in Firefox 3 is a little status indicator that can be found at the bottom right of your browser window:

Firefox will now let you know how much time is left for your active downloads. When you click on the indicator, it will open up so you can see more detailed information about your active downloads.

That wraps up the changes to the UI. Stay tuned for a post about what new features have been added to the download manager in Firefox 3!

Over in Bug 429986, I’m working on an asynchronous API for storage statements. In an effort to get more feedback on this proposal (and more ideas and brains thinking about it), I’m posting this to Planet Mozilla. So please, take a look at the proposed API with code samples, and then provide some feedback in mozilla.dev.planning.

An interesting usability study being done at CMU was brought to my attention recently, so I thought I’d give it a bit of free PR since the Mozilla world will probably be interested at least a little in it.

It looks neat, so if you use Thunderbird, you should check it out.

For one of my classes, we got to pick a project of our own choosing that uses multithreading in some way. My initial project wasn’t working out well, so I recently decided to try my luck with a Mozilla idea - making places use a background thread whenever possible. I do believe I’ve just scratched the surface, but I figured I’d share what I’ve gotten so far.

• Patches
• Builds

It turns out that the nsIThreadManager is pretty easy to use. Basically, I create a background thread when the nsNavHistory object is created, and shut the thread down when it is destroyed. So far I’m just failing one unit test, and that’s because it’s expecting the api calls to be serial so that the database is updated immediately. This code is neat because I’m doing at least one thing in a more modern manner than what most of our codebase is. I’m using namespacing quite extensively, which is pretty much a foreign concept as far as I can tell. I like it a lot though, and it’s making my code easier to follow.

I did learn some important things while doing what I’ve done so far though:

1. Our storage API pretty much sucks when you start to throw threading at it. I fixed the biggest issue in the first patch on my queue, but my fix is hacky at best. Suggestions welcome.
2. hg with mq is really awesome when you want to make lots of smaller easier to review patches
3. Unit tests are awesome when you are refactoring code.
4. Our perf results are completely unapproachable if you don’t already know what you are doing. If someone could tell me what if I helped or hurt things (or even how the hell to read the numbers in a useful way), I’d greatly appreciate it. Stats are on this tinderbox for the next 24 hours, and then I don’t know where they go.

I have to do a report for this project, so I’ll be posting that as well when I get closer to being done.