Typing multiple words and not being restricted to just matching at the beginning of the URL to match the domain provides a lot of power to the user.

I’ve put together some examples of how the Smart Location Bar can save you seconds, even minutes, every day when using websites like YouTube or Gmail or any place you can visit through Firefox. (Don’t miss the pro-tip at the end to easily read your new messages in Gmail! )

Ever visited a page but don’t remember the site’s URL or even the the domain? When you’re clicking through Google search results, you might find what you’re looking for but forget to make note of the URL. Many times you can just type in what you were searching for and Firefox can find it right away. Firefox will even order the results based on better matches.

Easily go back to pages without typing the domain

In most other browsers, you would have to start typing out “www.blizzard.com” if you remembered it and then additionally type “/diablo3″ to find the Diablo III related pages. Using Firefox 3’s Smart Location Bar, you could easily jump to what you want and perhaps find non-Blizzard pages that you might be interested in because you don’t have to remember to type the domain anymore.

A lot of pages on the Internet have URLs that are completely filled with junk — at least totally unmemorable for the user. Most likely the title of the page will have something much more useful. One prime example is YouTube where the video URLs are just some way for YouTube to know which video you want.

You’re more likely to remember the title of the page, which directly relates to the content of the video that you previously watched, than remembering even half of the random characters used to identify the video.

Quickly find previously viewed YouTube videos

In this case, I was trying to find Wind Garden [youtube.com], an 8-bit remix of a really great song from Super Mario Galaxy. In other browsers, if I wanted to try finding the page from my history and started typing out “yout,” I would never have found it because somebody linked that video to me from nl.youtube.com. I was able to find it with Firefox 3 because “yout” matched in both the title and URL ignoring the “nl.” part.

Another example of the AwesomeBar’s time-saving ability that will be popular with movie watchers is with IMDb - the Internet Movie Database. If you’re like me and can’t remember which movies every actor has been in, you’ll be revisiting this site over and over again. However, instead of always going to to the main IMDb homepage to find a movie using the search box, you can go directly to the page you want with Firefox 3.

Save time by going directly to movie page

These IMDb results show off yet another strength of the AwesomeBar — being able to match both the URL and title at the same time. Notice that “imdb” only shows up in the url. You can type “imdb” and then a word from the title to quickly narrow down the results to find the exact page you want. This saves you those extra seconds it takes to load the whole IMDb homepage and start a search.

You’ve got phone numbers, account numbers, social security numbers, personal identification numbers, and more numbers to keep track of. There’s no need to additionally keep track of IP addresses for those websites that don’t have easy-to-remember domain names.

No need to memorize IP addresses anymore

Cellphones let you easily find phone numbers by Contact name, and Firefox 3 lets you find IP addresses by Page name. Just like how you need to enter the contact name and phone number the first time on your phone, you’ll need to type in the the IP address once. But on the up-side, you don’t even need to provide a name for the IP address because Firefox 3 will automatically remember the page’s title for you.

Gmail has done a great job with their newest version by providing multiple points of access to their web application. Each message can be accessed directly by URL instead of requiring the user to first load the main Gmail page then searching for a message.

Get right to business with rich internet apps

Being able to access these multiple points of entry is facilitated by the AwesomeBar’s match-anywhere functionality. In this case, you would want to match page titles for email titles, but URLs can also be matched for commands like “new doc” for Google Docs [madhava.com].

By combining the AwesomeBar’s adaptive learning [ed.agadak.net] with the ability to start a Gmail search to find unread messages [mail.google.com] plus automatically selecting the first result [addons.mozilla.org] when pressing enter, I’ve been saving a lot of time whenever I check for new messages. All I need to do is type “mail” and press enter.

Digg it! Edit: Updated for post-Firefox 3 launch intro and a couple new examples.

However, this is an unexpected behavior for some users who want the location bar to be completely empty after clearing browsing history. So to address that, I’ve made an add-on that hides pages (bookmarks) that you haven’t visited (since deleting or clearing history) from showing in the AwesomeBar.

Only visited pages (and bookmarks) are shown

Hide Unvisited [addons.mozilla.org] makes it so that you can visit websites, potentially those that you’ve bookmarked, and later open the History panel and delete individual pages or whole sites from your history to then have the bookmarked pages also disappear from the Smart Location Bar’s suggestions. Once you’ve visited a bookmarked page, it’ll appear in the suggestions like normal except there’ll be a star and tags if you’ve tagged it.

“This add-on is absolutely fantastic and does exactly what I wanted it to do and most likely what many others will want actually.” - Misa! [addons.mozilla.org]

Check out other add-ons I’ve written like Edit Middle [ed.agadak.net].

For example, if you accidentally type “mozzilla” you can correct the typo to be “mozilla” and see the pages you were looking for right away. Or if you type “addons” but meant to type “add ons”. Or maybe you searched for “ginger carrot cake” [dria.org] and want to search for “orange carrot cake” instead.

Fixing “midle” typo to “middle” instantly shows results

Download Edit Middle [addons.mozilla.org] from the add-ons website or use the add-ons search from within Firefox 3. “Edit Middle” works for Firefox 3 including those using release candidates as well as nightly builds.

“Very helpful for those with less than 100% keyboard accuracy!” “Search relies on keyboard input and typos are a fact of life; this just makes the smart location bar that much smarter.” - bharuch2, Harlequin99 [addons.mozilla.org]

Thanks everyone who helped test, provided feedback, and reviewed my first add-on.

Turns out that the patch that I sent in to the dev list ended up making it in to Mercurial 1.0 [hg.intevation.org]. No official reviews, no comments. They just checked in the patch to their “crew” (trunk) repository and let it bake for several months. Seems like nobody complained enough to have it backed out and here it is now in Mercurial 1.0 as we can see on hg.mozilla.org.

But this post isn’t about the differences between Mercurial and Mozilla. It’s about the current Mozilla CVS development process vs Mozilla with Mercurial.

One main difference is changesets. Instead of having a separate version number for each file as in CVS, all related changes are grouped together for a changeset. These are the steps one needs to do right now to see all related changes of a patch: 1) use mxr to find the file you’re editing 2) switch to blame to find the checkin 3) click the bug number if provided 4) hope there’s a clearly marked patch as the one checked in to see what else was changed.

With Mercurial, you can just look at the changeset which contains everything; e.g., patch to not need to click the page to use gmail keyboard commands [hg.mozilla.org]. Additionally, now with my patch for showing line numbers in changesets, you can link people to a specific line in a patch [hg.mozilla.org]. This could be useful if you need to point to a particular line in a bugzilla comment about why it broke something. Or especially useful with a stack of patches on mq and you’re collecting feedback on it from other people.

Another aspect of changesets is that there’s a “global version” for the whole repository. You can jump back in time to an earlier revision and view the whole repository as it was before a particular patch was checked in. We currently have something like this on a per-file basis with bonsai, but you need to do so much more work to look at “the right version” of other files. E.g., going back to when adaptive learning was checked in [hg.mozilla.org], you can see that the autocomplete was still only emphasizing the first match in the url and title [hg.mozilla.org].

Of course, you can just use the mercurial web interface to view the latest version of the file. Just take http://hg.mozilla.org/cvs-trunk-mirror/index.cgi/file/tip/ and append the file you want. (Normally “tip” would be a changeset/revision hex number, but you can put in “tip” because it’s an alias (tag) for the latest version.) And from there, you can look at the whole patch for the current version (changeset), browse the checkin history of that file (revisions), or look at the blame (annotate) [unfortunately it doesn't have checkin comments on hover yet].

Typing out that whole url might be cumbersome, but good thing we have the AwesomeBar with multi-word search on word boundaries (with camel case) plus adaptive learning. “hg. auto” [hg.mozilla.org]

I’m not sure how distributed the development process will become for Mozilla, but these neat tools provided by default with Mercurial will make it easier to track changes and refer to them in bugzilla comments or over IRC. (Oh, and if you’re using mercurial and haven’t looked into mq yet, you should do so. It’s a great (builtin) extension to track/reorder multiple patches that you’re working on. And for those curious how I send changes for try-server builds, I apply the stack of patches and hg export firstpatch:lastpatch > combined.patch )

(But for those curious, I presented Branch-on-Random [pdf, uiuc.edu] at CGO 2008 [cgo.org] (Code Generation and Optimization). Basically, it’s an instruction that’s really cheap to implement and allows for a factor of 10 times less overhead than traditional sampling techniques. I think it went well, and I even got asked during Q&A.. “When can I buy one of these?” )

As we’re winding down to ship Firefox 3, there aren’t as many more big features, but there’s still some useful changes in Beta 5 in terms of functionality, display, and performance. So those of you who have installed extensions to make the auto-complete smaller might want to turn it off to try out the new look.

Functionality

To better accommodate people’s expectations of results in the auto-complete, there are frecency tweaks to better prefer pages you’ve typed — by default, before adaptive learning. This helps address concerns that the top level site’s main page should appear high in the list because typically people are typing in the domain.

Another common complaint is that results seemed to be returning useless results when typing 1-2 characters. This stemmed from results being matched in the middle of words instead of at the start of the domain, for example. The adaptive learning helps avoid this problem because you’re typing words and selecting results that matched the word you wanted. The learning system then knows to show that selected page over others when you just type a single letter of the word — effectively showing a result that matches at the beginning of the word.

So to improve things for Beta 5, words that you type in the location bar will try to match on word boundaries e.g., matching after a forward slash or space. This even works for CamelCase (capitalizing the first letter of words instead of putting spaces) which is common for wikis.

Searching for “wik m” matching on word boundaries

Display

The first thing people will probably notice is that the list doesn’t feel as overpowering anymore. The number of results shown on the screen has been reduced to 6. Additionally the font size of the title text is smaller which felt unnecessarily large on some platforms like OS X. Ideally, the fewer number of results will help users scan results quickly instead of feeling overwhelmed. Combined with better functionality of multi-word search, adaptive learning, and word boundary matching, finding the page you want should be a happy experience.

Another set of changes is for how words you type get emphasized. Instead of only showing the first match in the title and url, it’ll emphasize all matches. Additionally, it’ll show matches when you type multiple words as well, so each word gets emphasized instead of nothing at all. For browser skin designers, there’s a new css class to alternatively emphasize matches, but the main purpose is to avoid styling bold which breaks common ligatures in some languages.

Bold/underline for english, just underline for ligatures

Performance

There has been improvements in browser responsiveness in Beta 5, so now it no longer eats up all of your CPU power for every letter that you type. In Beta 4, every single letter you typed caused the browser to start searching through your whole history

To optimize for users typing letters one by one for a whole word, we now reuse the results that are currently being shown in the list as well as continuing the search from where the last one left off. This has 2 main effects outside of reduced CPU usage: 1) existing matching results show up immediately instead of disappearing momentarily then reappearing and 2) not-as-frecently visited results can be found faster as you continue to type.

CPU usage when searching in Beta 4 and Beta 5

The picture shows a CPU usage graph where high bars means the CPU is doing a lot of work (and potentially not letting it update the UI). The horizontal axis is time and each set of 5 bars shows the 5 seconds after typing a letter one by one. So comparing the two graphs, we find the same results with a lot less work.

As an informal poll, I was wondering how many people are using the unofficial tryserver builds that I’ve been making. There’s some features like showing keyword searches, restricting searches, etc., that might not make it into Firefox 3 final, but I could potentially start a build near ship time, so you can get Firefox 3 + some extra awesomeness.

In general, I like to ask “why?” to figure out why things are done, why they should be done, what are other ways to achieve the same goal?

I don’t remembering ever getting an explanation on why there was a requirement. I suppose the obvious answer was that we now have a testing infrastructure, and we don’t have many unit tests, so you need to write them. But still, that’s not a great motivation for writing tests.

So, why should you write unit tests?

1. Make sure your code does what you want it to do
2. Speed up development and optimizations/refactoring
3. Create better interfaces and functionality
4. Get other people to use your contribution
5. Make sure nobody else breaks your feature

This isn’t an exhaustive list, but these are things I’ve noticed from my own experiences.

Make sure your code does what you want it to do. The first reason is somewhat obvious, but it’s effect isn’t. I believe one big benefit is that it lets you change how you write code. Specifically, it speeds up your development in that you don’t have to completely think through what you’re doing. That might not sound too great, so I’ll try to give an example.

When working on word boundary matching for the AwesomeBar, I had automated unit tests set up with a set of pages and a set of searches, and it made sure searches matched on word boundaries (like spaces, dots, slashes and not after other characters). I needed to write a string processing utility that matched on word boundaries that would work for standard word boundaries as well as CamelCase and not break search for ideograph languages like Chinese.

I was never one for too much theory, so instead of sitting around and explicitly drawing out all the boundary conditions, I made simple code changes, recompiled, checked if the tests passed. Instead of sitting around for 10 minutes thinking deeply about how to deal with multiple word boundaries in a row, I made a 1 second change and ran the test to see that it passed.

The point there is that you can spend less time trying to reason about if the code will do what you want and just let the computer automatically do the checking. You already specified what the code should do with your test, and the computer can quickly make sure that they pass. This also relates to speeding up development (or perhaps avoiding my impatientness) because I don’t need to go through the long process of firing up a debug build to make sure my manually typed search terms find the expected pages — I don’t even need to make sure I have the right profile with the right set of test pages.

Speed up development and optimizations/refactoring. I mentioned speeding up optimizations and refactoring, but the former is basically a special case of the latter. Both tasks are making changes to the code without changing functionality. With automated unit tests set up, you can be sure that your refactoring changes don’t break expected functionality. For example, as I was optimizing the AwesomeBar to go faster and use less CPU cycles, I relied on the unit tests to make sure searches still provided the same list of urls.

In fact, one of my unit tests caught a bug in my first optimization because I forgot to check for javascript: URIs. The optimization reuses previous search results if the new search begins with the same text as the previous one, but we also do some special processing for javascript: URIs. Namely, we don’t show javascript: results unless you explicitly type out “javascript:” at the beginning of the query. So if you were searching for “javascript” and then typed “javascript:”, the optimization wouldn’t have shown any javascript: URIs because the previous result couldn’t have contained javascript: results.

Create better interfaces and functionality. Good APIs are fun to test. I enjoy writing AwesomeBar tests because I just need to provide some search words and a set of expected results. Simple. But you can also have better functionality because the process of writing tests makes you a user of the API. You start thinking about “what else” or “how could this be better.”

For a might-not-make-it-to-Firefox-3 feature of being able to restrict results to non-bookmarked pages or forcing matches on the url (by default), I wasn’t sure at first how things should interact if you have multiple “restricts” or “matches”. By writing the unit tests, I was able to easily look at all possible combinations such as “must match url and must match title”. Because I was writing the test, I noticed this potential issue and got it clarified; otherwise, it might have remained a not-well defined feature.

Get other people to use your contribution. I like to learn by example, so if I want to use something that I don’t know how to use, I search for existing uses of it in the codebase. A good description of a class/method is nice and all in the interface description, but seeing it actually used is much more helpful for me. Ideally test cases are written to test representative usages of a feature, so someone looking at the test code should be able to reason about how they should use the interface.

I’ve written up a couple unit tests for the PluralForm module, and they serve as additional examples of how to use PluralForm. I’ve written up some PluralForm documentation [developer.mozilla.org] on how to use it in Firefox and extensions, but without the unit tests, someone searching for PluralForm would have to rely on the current usage in the Download Manager. And relying on that would make things more confusing as one would have to look through a lot of unrelated-to-PluralForm download manager code.

Make sure nobody breaks your feature. You just worked really hard on adding a new feature. You don’t want it broken. I suppose an alternate motivation is that the blame goes to whoever breaks your test. If you didn’t have the test, potentially you would be stuck fixing it some weeks/months later. Also, with unit tests, it’s easier to see how the code is being used, so the person breaking the test should be able to fix it faster.

Tests aren’t just “for the future.” They help fix things now and help you go faster. And if you’re doing a lot of development and frequently touching the same piece of code such as having a huge stack of patches for a single file, unit tests help make sure patches can be applied without other patches, and if not, you know it wasn’t going to be safe to “cherry pick” a patch out of the stack and check it in.

I’m sure there are other benefits of writing automated unit tests, but I think this is a good starting list of motivations. Hopefully better than “why didn’t you write a test?!”

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.

There have been a lot of positive comments already: searching for multiple words like the domain plus title, adaptive learning that immediately brings previously selected results to the top.

But there are a few that say the desired results aren’t showing up. I’m not sure if they haven’t tried Beta 4, or if they’re just commenting based on previous versions. Or maybe they’ve installed extensions that revert the look of the location bar and haven’t really tried the new features.

Common complaints include typing “news” and getting results that match in the title instead of the url. However, that should be instantly fixed when the user selects the desired result from the list after typing out more of the url. Next time typing “n” will have the previously-selected page at the very top.

Below is a sample thought process that could only be possible with the AwesomeBar*.

I’m trying to find a news article I read yesterday..

The first result has news matching at the beginning of the url

Oh, it’s matching a lot of pages that I’ve tagged. I know it’s something in my history that I haven’t bookmarked.

Restrict results to non-bookmarked pages

Much better. I actually see some Firefox results that I was looking for to begin with. Let’s filter out the pages I don’t want.

History pages that match the url and title

Beta 2? Beta 3? I just want beta 4 news articles!

String matches for pairs of words like “beta 4″

Perfect! I love the awesomebar! Hehe, thanks shaver.

* The screenshots were taken with a trunk build (win32, os x, linux [build.mozilla.org]) that contain some patches: 393678, 419656, 417441, 415397, 421315, 407946, 415403, 418257, 392143, 249468, 395161, 407204, 406257, 420437, 414326 [bugzilla.mozilla.org]. Feel free to try it out and see if it finds results better or just looks better (6 rows and smaller font size).

* edited downloads to include word boundary matching

Firefox 3 Beta 4 will have this feature. Everyone will be able to play with it in just a couple weeks.

Adaptive learning puts your most selected results first

The adaptive learning even works for the drop down menu without typing any words. So those who prefer using the mouse can benefit as well. But if you ever do select a page after typing some words, it will also learns to show those results when you click the auto-complete drop-down.

But that’s not all that’s new in Beta 4. There has been many improvements to the location bar since Places landed, and here’s a short list of changes since the first beta.

Beta 1: Search page titles and urls - not just the start of a domain; Match page tags
Beta 2: Two line view with title first; Emphasize first match in title then url
Beta 3: Global frecency for better ranking; Search bookmarked pages; Emphasize first match in both title and url; Unescape url-encoded URLs

Outside of adaptive learning for Beta 4, there’s also the ability to search with multiple words [ed.agadak.net]. I first wrote about the feature letting you find pages that match the domain and a word from the title.

It’s even better. You can also match against the tags you’ve added to pages, so you can just treat the tags as extra text in the page’s title, except they’re common across multiple pages. This means you can type a tag, a domain, and part of the title to get the exact page you want. As a bonus, the pages are treated like any other page, so they aren’t specially placed at the top of the list, and you don’t even need to type out the whole tag in the same order you tagged the page to match it.

So what else is there?

Well, it’s already Beta 4, and there isn’t much time left to keep adding features. But I’ve got some neat things that are somewhat geared towards more advanced users. Whether or not they make it in for the final version of Firefox 3 is in the air. I’ve already implemented them, so we’ll just need to see if people have time to review and approve the changes.

Only search pages with a star

First up is being able to restrict search to certain pages [bugzilla.mozilla.org] such as those that you’ve bookmarked, which have a star in the drop-down. You can type a single “*” at the beginning of the search and do the multi-word search as normal, except only bookmarked pages are searched. Also, you might notice that pages will show which tags they have [bugzilla.mozilla.org] and where they match.

Only search through history

On a similar note, you can also use “^” to find pages only from your history — pages that have not yet been given a star. I find myself using this type of search without additional search terms to find pages that I’ve frecently visited, and perhaps I would want to bookmark and tag them. One last special search is with “+” that restricts the search to tagged pages. Of course you can customize the character you want to type for the special search, so you can make it “!” or even “z” or more verbose “tags”.

Show the keyword search

Another feature helps show a powerful feature of Firefox. Keyword searches. Basically, they’re special bookmarks that you can create by opening the context menu on any search box of a website. You give the search a keyword, and then in the location bar, you type that keyword and the terms that you would have put into the box on the web page. You can easily search for content such as Wikipedia pages, YouTube videos, IMDB movie information, and more.

Except now, you get a keyword auto-complete entry [bugzilla.mozilla.org] showing which page you’ll be going to. Additionally, you can even reuse the same keyword for multiple searches because now you can pick which one gets used.

Search with phrases

Sometimes treating each word as a separate search isn’t quite enough, and what you really want is two words right next to each other. Perhaps you want to find that page that tells you how to bug mozzy (… ), but all your searches for “bug moz” finds bugzilla bugs! Just put the phrase in quotes and you can search quoted strings [bugzilla.mozilla.org]!

Emphasize all matches for all words

You might have noticed in the previous screenshots, multiple parts of the result get emphasized. For Beta 4, it’ll only emphasize words that match as the phrase, so most of the time, if you type multiple words, it won’t emphasize anything. The screenshot above shows “a” matching in all places [bugzilla.mozilla.org], not just the first. Additionally, all words/phrases [bugzilla.mozilla.org] are treated separately when showing matches.

For the very observant crowd, you might have already noticed the screenshots have a smaller font size for the page title [bugzilla.mozilla.org]. But additionally, the number of rows has been reduced from 10 to 6 [bugzilla.mozilla.org]. Hopefully, being able to find pages with multiple words against the title, url, and tags in additional adaptive learning will lessen the need to show 10 results by default. There will be fewer results for you to scan, but you can also filter pages more easily by typing another word that you know to be in the title or url.

We’ve come a long way since Firefox 2, and we’re getting really close to shipping Firefox 3. But hopefully there’ll be some time to get in at least some of these features.

PluralForm for Developers
To get the correct plural form of a word in Firefox or an extension, the javascript file just needs to import the module and call a method.

// Load the module at the top of the javascript file
let Cu = Components.utils;
Cu.import("resource://gre/modules/PluralForm.jsm");
// Get "word" or "words" based on the number
let word = PluralForm.get(number, "word;words");

In this English example, there’s only two words, but other languages might need fewer or more. More information about what string to give to PluralForm.get() for various languages is on the devmo wiki page Localization and Plurals [developer.mozilla.org].

So anywhere in your code you’re doing something like..

let string = number == 1 ? singular : plural;

.. you might want to consider using the PluralForm module.

PluralForm for Localizers
To help localizers make sure they’re correctly localizing the plural strings, I’ve created a pluralForm Checker extension [ed.agadak.net xpi 3.6 KB].

Strings can be checked to have the right word for a corresponding value

With this tool, localizers can list the property files and properties that have plural forms to check. Each string is split up into its appropriate plural form and there’s a sample output display at the bottom for the first few numbers of each plural form.

Notice that “words” don’t necessarily have to be a single word.

pausedDownloads=One paused download;#1 paused downloads

Of course, for a language that has multiple values that are treated as singular (1, 11, etc.), the first paused string can’t be hard coded to “One”.

DownloadUtils
In fixing the bug, there is now also a DownloadUtils.jsm module [mxr.mozilla.org].

This provides some useful methods for downloads such as displaying file sizes, transfer times, and download locations. Once again, it’s loaded just like PluralForm.jsm using Cu.import(), and it can be used in Firefox or extensions.

For example, right now the automatic updates dialog still uses the old download strings from long before: “1.2 of 8.4 MB at 146 KB/sec; 00:32 remain”. We could use DownloadUtils to make it consistent with the redesigned Download Manager for Firefox 3 to be “32 seconds remaining — 1.2 of 8.4 MB (146 KB/sec)”. This mean it would also get the benefits of being able to display “days, hours, minutes, seconds” and “GB, MB, KB, bytes” as well as time smoothing. (Hopefully updates never take that long or are that big.. )

This DownloadUtils.jsm module helps simply implementing download related displays such as the new download activity summary in the status bar [bugzilla.mozilla.org].

Download Activity Status Bar
Thanks to Michael Schonfeld, we can now monitor downloads from the status bar!

Michael first uploaded a patch to the bug [bugzilla.mozilla.org] out of nowhere about a month ago. I had him wait on me because he would be running into issues with plural forms and download strings. After I landed the patches for PluralForm and DownloadUtils, Michael was able to quickly update his patch in about an hour to be ready for the l10n string freeze. (Additionally, the original patch went from 22.13 KB to 5.76 KB just to show how much the modules simplified things. )

A brief summary of downloads for easy user monitoring

Personally, I’ll be turning off the preference that shows the download manager when a download starts. I can now open files without having an extra window pop up while still knowing how much time it’ll take. As for saving files, I can easily alt-click links to save many files at once without being interrupted with the download manager flashing.