I’m looking into ways to improve how people search in Firefox. My previous contributions focused on getting useful pages to show up in the AwesomeBar when searching history, and I collected plenty of useful feedback to see what users wanted or didn’t want in the results.

I’ve written a restartless add-on that lets you see how you use the searchbar in Firefox. It scans through what you’ve previously typed into the searchbar and groups your searches by the words you’ve typed. The first set of results shows words that you frequently use across different searches, and the second set shows searches that you repeat multiple times.

If you’re running a recent Firefox 4 beta [mozilla.com], install the add-on, and it’ll open a new tab with your results (without sending that data anywhere). This is a restartless add-on that will also uninstall itself after it runs.

If you feel like sharing your results, please leave a comment or send me an email: edilee@gmail.com.

Unique and repeated search queries from my own searchbar history data

From my personal usage, the unique search queries set has many searches that I only do once to find out information on some topic like “mozilla” or “starcraft”. This contrasts with my repeated searches where I have terms like “time” or “movie”. I do make heavy use of keyword searches and smart bookmarks, but I happen to not have set any for these repeated searches probably because search engines like Google and Bing provide useful information on the results page.

Are your results like mine? Do you have a totally different search behavior? Any suggestions for how you would improve searching?

As Atul mentioned in “The Social Constraints of Bettering The Web” [toolness.com], Account Manager will likely not make its way into Firefox 4. He points out one of the biggest bottlenecks as getting approval from Firefox product drivers:

Within Mozilla, I see my coworkers vie for the attention of this tiny handful of gatekeepers. People in charge need convincing; the clever social engineer has a lot of power when it comes to navigating this landscape.

This last step of getting approval comes at the very end of a long line of work. While Dan and I have been busy implementing the core feature and making sure it doesn’t regress performance and tests, a good number of people have been involved both inside and outside of Mozilla to design the user interface, to flesh-out the spec and to integrate the feature into sites or as plug-ins.

Alex Faaborg's mockup of letting users pick different types of accounts

But this approval process affects people outside of Mozilla as well. New developers in the community hear about neat features of the upcoming Firefox and want to help by hacking on patches of related features. For example, the status bar removal in Firefox 4 has a number of side-effects including the removal of the download statusbar. Alex Limi has suggested ways for “Improving download behaviors in web browsers” [limi.net], which would add a new toolbar interface, and while there are initial patches from multiple community members, it seems unlikely to make it to Firefox 4.

I even ran into this same roadblock a couple years ago when I was trying to get the AwesomeBar into Firefox 3. Back then I was a random community member that had a good idea and was able to hack on stuff in my “free” (ha! ;)) time. It was only after a lot of prodding and persistence that got just a bit of what I worked on into Firefox 3, but that was all very stressful as I looked back on “Why I Worked On Firefox.”

But fear not community members! There’s always another release. The product drivers are not approving patches during this beta-crunch time because there’s always some risk involved with changes (especially those “it’s just a one line change” fixes :D). New changes typically are followed up by a number of new issues and patches that then need to be additionally hacked on, tested, reviewed, and approved. So just because it doesn’t get approval now doesn’t mean it won’t be accepted when the tree is more open.

Additionally, patches usually come with a number of dependent fixes that might be able to land first. And in the case of Account Manager, I’ve already gotten in some changes into Firefox 4 that improve the new PopupNotifications (used by Geolocation and Add-ons) and testing infrastructure. Some other useful changes that could land independently of Account Manager are some upgrades to the Password Manager and networking APIs. So while the core feature might not be in yet, the platform is made better and ready for it.

So keep hacking away and perhaps your feature will be ready to land on the open tree after Firefox 4 branches. And then it’ll have many months to bake and get tested by other community members and eventually be seen by millions of Firefox users. 🙂

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!

I’ve got a change that should speed up the Location Bar in Firefox 3.1 and 3.2, but I just want to make sure it’s not only me and my computers that are seeing this benefit.

For you to take the test, you’ll need to be running a Shiretoko (Firefox 3.1) build or Minefield (Firefox 3.2) build [ftp.mozilla.org].

What you then need to do is type something that will search through all your history, such as “this page isn’t in my history yay”. Just copy/paste that into your location bar, but keep track of the time you pasted and the time the activity throbber stops spinning in the location bar. (If you do get results, it’ll still be okay, as long as the location bar didn’t find 12 results.)

Depending on how much history you keep and how long you’ve been using Firefox 3, this could take over a minute or two before the throbber stops spinning.

Once you record how many seconds it takes for the throbber to stop, repeat the same thing with the Firefox 3.2 build that includes my optimization [build.mozilla.org].

CPU Usage (1 bar/sec): Old Firefox 3.1 takes 2 minutes; New takes 20 seconds

I’ve tested this on a few Places databases with my current unibody MacBook and my old iBook, and both times it runs much faster. Some times it goes 6 times faster. With one test on a database with over 100,000 places, the location bar throbber stop spinning in 20 seconds instead of 120 seconds.

Please report back your results as comments, and if you’d like, go ahead and vote for the bug, Make location bar autocomplete even faster [bugzilla.mozilla.org], to follow its progress.