But one thing caught my eye in the spec he linked, harmony:arrow_function_syntax:

// ''=>'' has only lexical ''this'', no dynamic ''this''

This means you no longer need to bind or do the self = this dance. Both patterns are common for setting up callbacks in JavaScript.

So if your code in a method of an object used to look like either of..

addEventListener(.., function(event) {
  .. this.value ..;
}.bind(this));

or

let self = this;
addEventListener(.., function(event) {
  .. self.value ..;
});

Your code can now look like this!

addEventListener(.., event => {
  .. this.value ..;
});

Exciting stuff!

Common web pattern of users agreeing to terms

So far what I’ve described seems compatible with the Open Web because Firefox can expose access to the user’s data through a web API such as geolocation where the user confirms or denies the request. One main difference is that the site agrees to the user’s data privacy contract — perhaps through an electronic signature. But even then, this difference isn’t too foreign because this digital agreement pattern seems common on the web — except most of the time, it’s the user agreeing to the site’s terms.

One followup idea, regarding who is creating contracts, suggested a non-profit who cares about the Open Web and users’ privacy could be well suited to negotiate with web sites. Instead of having each user provide a user data privacy contract to each web site, Firefox could refer to a list of allowed domains that have already agreed to the non-profits requirements on how user data from the browser can be used. Of course Firefox would still give users control of what data is analyzed and to what detail is the data shared.

With these site-by-site contracts of agreeing to treat users’ data at a privacy level acceptable/required by the non-profit, it seems like a potential slow-but-steady way to improve the web for all parties: the site gets high quality user data, the user gets better personalized content, and Firefox protects privacy for users.

The tricky part here is that there would be a split between which web site have access to the web API: those who are contractually bound to treat users’ data correctly and those who are not. If Firefox only allowed access to web sites that have signed the contract, would this still be part of the Open Web? Is it necessary to have this as part of the Open Web? How about if general web access could be enabled through a user preference while also requiring user confirmation on a per-site basis from a scary looking dialog?

I’m sure there are plenty of other questions in this area of protecting users’ data while improving the Open Web experience. So please comment and provide your thoughts or questions!

I’ve been using about:trackers for a few weeks, and I’ve noticed some interesting side-effects of the add-on with social networks. But first to provide some more context, I’ll give some of my very informal observations on one aspect of how people use social networks.

People often log out of social networking sites when they aren’t actively using them. I’m not sure if they want to stop seeing their face on other websites (e.g., in comment boxes), or they don’t want the social network to be able to follow them to all the articles they read that have sharing widgets, or they just don’t want someone else from being able to post as them when they’re not around. Facebook even seems to leverage this fact that people often end up on the logged out screen and now shows content to users on that page.

Appearing logged out of Facebook when actually logged in

The interesting side-effect of the default policy in about:trackers is that I now appear logged out to Facebook even though I’m still logged in to Facebook. Now I can browse the web without actively logging out of Facebook when I’m done. This save me time from logging back when I want to use Facebook and logging out at the end while getting the best of both.

I can still see Facebook content on other sites such as the number of likes a page has and the Facebook comments because the embedded content is still getting requested — just without my personalization cookie sent to the servers. I do admit that I don’t actively click on like buttons or post comments, and some quick tests seem to indicate that functionality is not working.

Now that Social API is available for testing with Facebook [blog.mozilla.org], users have more reason to stay logged in all the time because they get easy access to friend updates and are a single click away to chat from whatever tab they are viewing in Firefox via the Social sidebar. But for some those who would have wanted to appear logged out otherwise, this unintended feature of about:trackers could help give more control back to users.

Edit: Tom just posted on the Privacy blog about this topic of being social with privacy in mind [blog.mozilla.org], and he goes into more detail about what happens now on the web with social networks. He also points out how the Social API can lead to better privacy because users are in control of when they inform Facebook of a URL by clicking the Like button in the location bar. Looks like both of us are helping users get more control of their data and privacy, and these two posts show that there are multiple options to get there.

Showing things you like on something you own

People seem to have all sorts of stickers placed on things they carry around, e.g., laptops, binders, or notepads; or a mode of transportation, e.g., cars, skateboards, or bikes. Even though showing something could be thought as a statement, I would guess that people aren’t necessarily always looking to have a conversation by displaying their sticker. They’re just happy to show off something they support or care about.

This note about having a presence without actively socializing seems to overlap in some way to the “Visitors” group from a study on Identity and the Internet [blog.mozilla.org]. Not everyone wants to be social on the internet and actively produce content, so using these stickers to show off one’s interests seems like a comfortable step from being completely without an online identity.

Do you use stickers? If so, what are you showing, where are you placing them, and why do you use them? I’m curious!

Overall categorization and detailed/recent interests

It shares some ideas with what Margaret implemented for about:me [wiki.mozilla.org] such as processing the local data within Firefox and not sending data out of Firefox, except in about:profile, we’re trying to generate higher-level concepts such as an interest category as opposed to statistics of your browser behavior. We happened to go with some readily available domain data of ODP categories and Alexa siteinfo, and we selected some hundreds of top sites to package into the add-on. So while the reference data is not an exhaustive list, it seems to work for quite a few people I’ve shown the add-on to.

Our somewhat arbitrary choices of category interests and site demographics got me thinking about what we could do with this data in Firefox, and I seem to keep coming back to this distinction of category data actually shows what I’m interested in whereas demographics appears to create a label/characteristic that opens things up to preconceived judgements. I suppose in other words, the former is based on something I did vs the latter is something I am. (Although technically, the about:profile experiment is trying to guess at who you are based on what you did.)

I’m sure others will be able to better describe the differences between the two, but I wonder if because there appears to be a fundamental difference, we should go about presenting the data differently to the user. For example, perhaps users will be happy to explicitly give Firefox one’s demographic data whereas trying to have the user create a list of interested categories might be overwhelming.

I’m excited that we’ve released the add-on to get a conversation started because there’s so many different ways to analyze the data in Firefox, and each method can lead to interesting discussions such as this one about categories vs demographics.

Just switch to the location bar by pressing ctrl/cmd-L, start searching, highlight the result you want, and press ctrl/cmd-enter. The url will be in the clipboard and automatically pasted to wherever you left off in the page.

And of course this works with Enter Selects, so you don’t even need to press down to copy the first result. Enter Selects automatically highlights it, so you can type out the page you want, and directly hit ctrl/cmd-enter and you’re done!

Try out Copy Selected or check out the code on github. (This is neater than I expected! I just used the functionality 3 times in one post. )

If you’ve previously used Enter Selects, the behavior will now be the same as it was before — pressing [Enter] after typing in the AwesomeBar will automatically select the first result from the list. This is different from the new inline autocomplete behavior of completing a domain or url that begins with the letters you’ve typed.

Enter automatically selects the highlighted first result.

Enter Selects’ behavior is good for you if you tend to type words that match in the title or mid-url or use multiple words where the AwesomeBar’s adaptive behavior will push these non-prefix domain matches to the top. If you do want inline autocomplete after Enter Selects highlights the first result, just press [Up] to edit or load the inline-completed url.

Just as before, Firefox’s adaptive learning behavior will push the sites that you frequently visit to the top, so quite quickly, you’ll be able to type 1 letter and press [Enter] to go to the page you want.

I’ve also revamped the code from the original Firefox 3 implementation to be restartless by using the Add-on SDK [addons.mozilla.org]. Additionally I converted the repository from hg to git for people to fork [github.com].

“what a fine add-on! Saves so much on needless keystrokes!” “Thanks a lot, this function is easy but necessary, now I can forget about chrome~” “This is the BOMB! This should be a built-in feature in Firefox, as it is with IE9. Keep up the good work!” -st3ve, yaapal, Deep Thought [addons.mozilla.org]

Try out restartless Enter Selects in Firefox! [addons.mozilla.org]

Colorful tabs appear along the whole bottom edge on install

Here I’ve used the dominant color to add search engine tabs to the bottom of the screen. Normally they’re hidden away, but when you first install the restartless add-on, all the tabs appear for a few seconds. You can also see that all installed search engines are available, such as the one for Twitter Address Bar Search.

Selecting text shows colored tips

When you select some text or start typing in a text box (including those in the Firefox interface like the AwesomeBar!), the tabs will peek up from below only to show their transparent color-filled tips. If you do point at one of the tabs, it’ll become fully opaque and pop up to show the icon. Clicking it will let you search for whatever you have selected or typed.

Install Search Tabs on Firefox 4 without needing a restart. Just reply back in comments if you have any feedback. Or check the code on GitHub and file suggestions or issues!

After installing the add-on, hold shift while pointing at an image to have it report the color and show it behind the image. One slight difference from Margaret’s code is that color and transparency values are rounded down to a multiple of 16.

Pointing at an image in about:addons

Download the add-on and check out the code!

YouTube, Pandora, Gmail

• Problem: Video/music/flash keeps crashing when clicking links, e.g., related videos or skipping songs
• Plugin: Upgrade to Flash 10.2.152.26 (Feb. 8 update)
• Context: Firefox on Windows added Crash Protection with 3.6, and OS X users will no longer worry about plugins taking down Firefox in 4. But there was something different in Flash for Mac that was tickling Firefox in just the wrong way at the wrong time that resulted in many more plugin crashes. (Good thing Firefox could keep running and others tabs were unaffected.)
• Learn more: Adobe security bulletin, bug 572134

Netflix

• Problem: Trying to watch a movie always shows “Once installation is complete please restart your browser to watch this movie.”
• Plugin: Upgrade to Silverlight 4.0.60129.0 (Feb. 14 update)
• Context: One major feature in Apple’s latest operating system is 64-bit Snow Leopard, and Firefox 4 combines that with its speed improvements to go even faster. Unfortunately, existing 32-bit code, e.g., Silverlight plugin, doesn’t always play well with the new 64-bit code.
• Learn more: Silverlight 4 update, bug 598406

Amazon.com

• Problem: Lightning deals don’t show up on various pages like Gold Box pages
• Context: Firefox 4 supports ECMAScript 5 "strict mode", which makes writing JavaScript code easier and cleaner. Amazon.com combines multiple files, e.g., its own code and jQuery, into a single file to speed up the site; however, jQuery uses strict mode, which applies to the whole file, and some of other other code was no longer valid.
• Learn more: bug 579119

Yelp

• Problem: User-submitted photos, map navigation, search filters don’t appear or don’t work
• Context: Firefox 4 implements many parts of HTML5 from the <video> tag all the way down to the nitty-gritty details of what properties exist on certain HTML elements. Yelp’s code was counting on "style" in HTMLElement.prototype to be false, but HTML5 browsers will now give true instead.
• Learn more: bug 608651

So if you haven’t tried Firefox 4 recently because your favorite sites weren’t working, download Firefox 4 beta or have Firefox update itself and try again now. Thanks to the excellent work from all the teams involved to make sure Firefox 4 works great when the release candidates and official release appear in the coming weeks.

So briefly, I’ve put together some helper functions [github.com] that have been useful for developing various restartless add-ons. I’ve organized the repository to have a bunch of “examples/” branches that build on top of other named branches that implement helper functions.

These first few are very simple examples:

- examples/autoReload: saves a step when developing a restartless addon by automatically re-enabling when you disable the add-on from about:addons

- examples/ensureEnabled: the install method always gets executed even when disabled, so this code makes sure the add-on runs on install; useful when combined with the following..

- examples/oneTime: run once and disable itself; useful for debugging problems on other people’s Firefox without doing the usual “copy/paste this into the Error Console”

The next couple helper functions have been incredibly useful for the restartless add-ons I’ve written:

- unload: add a callback to run when the add-on is disabled by calling unload(callback). This function makes it easy to ensure Firefox returns to its original state when a restartless add-on is disabled (which is very important for developing as you’re likely to disable and re-enable many times!) (example)

- watchWindows: add a callback to run when the main Firefox browser window is open (navigator:browser) by calling watchWindows(callback). The callback will be called immediately for existing windows and future windows, so put whatever browser UI modification code you want inside the callback. (example)

One last helper in the repository is the getString function that adds some l10n support to get the correct .properties file for the current locale. It shows off getting additionally packaged files and picking the right locale and some plural forms. I’ve put together a silly example at examples/l10nDialogs.

With all these helper functions, Erik Vold and Nils Maier helped put together some code that loads packaged scripts. We ended up with some code that makes use of getResourceURI so that it correctly works if the addon is .xpi packaged or an extension proxy file. Separating out the code this way lets you better organize the code and makes it easier to share.

I started hacking on an idea last week in the context of the Prospector experiments [mozillalabs.com]. I’m looking for a small set of people to try it out and give some initial technical feedback. For example, I know I’ve hard-coded some sizes/images that happen to fit my 1280×800 screen on my Mac, but I am curious how it works or doesn’t work on other platforms, window sizes, etc.

You can install the restartless add-on [edit: addons.mozilla.org] if you’re already running Firefox 4 Beta 10 [firefox.com] or later. I’m not really describing it on purpose. But not to be too confused, below is a sketch from when I started hacking on it. And as usual, you can check out the source first from GitHub [github.com] or directly from the .xpi.

You can email me the feedback at edilee@gmail.com or just reply with a comment!

At the Mozilla All Hands last week, and we held a discussion to brainstorm various ideas to try out in the Prospector family of experiments. A couple of the current experiments like Speak Words and Instant Preview help users get back to top sites almost instantly with just one key stroke, but these mainly help for the relatively small set of sites that users frequent and not so much the remainder of the history available in Firefox.

So the next set of experiments will focus on improving the experience of searching for pages in Firefox. Interesting findings from Query Stats could help identify relevant pages or help build a better view of your past browsing behavior. Additional data about each page could be tracked by Firefox such as unique phrases from the page or how long a tab was opened and interacted with.

Displaying the search results also received some attention as to how to add all this extra information in a clean way. Some ideas ranged from being more space efficient by showing location bar results on one line to taking up more vertical space as one might not need to use the page when searching. This led to ideas of using the whole tab content area to show rich results and provide interaction such as grouping/switching of types of results like pages, apps, videos, etc.

- Prepare search bar -> button demo

Along the lines of combining the location bar and the search bar, I’ve been hacking together a Prospector experiment that changes the search bar into a list of buttons. This allows for explicit control for the user to decide when searching should be local to Firefox’s history or over the web. It also makes it apparent that there are multiple search engines to choose from and clicking another button switches the current search request to another provider.

When clicking a button, it inserts a keyword and focuses the location bar, so it’s like doing a smart bookmark keyword search with the first location bar suggestion being the search. Combined with Instant Preview, it’ll automatically update the results immediately as you type more words or switch engines.

- Attend Open Web App discussions

I was curious what kind of web-apps were being created in general across the various web-app stores available today because I wanted to see if the search bar -> button experiment above could add to the types of available apps. This is because generally speaking, these search buttons processes some words from the user and converts it to a url or a set of results.

From the screenshot above, the last button is actually for Google Translate, so when I click the button and type “hola mis amigos”, Google translates it immediately as I type to “hello my friends“. This somewhat feels Ubiquity-like, which had all sorts of commands, so potentially allowing the web app manifest to describe these “searches” or “actions” could lead to web-apps that are more than just bookmarks.

- Push restartless code examples to GitHub

I’ve been hacking on restartless add-ons for a while now and noticed that I copy/paste some useful helper functions for when I start a new add-on. Other people hacking on these bootstrapped add-ons could make use of them as well, so I created a “restartless” repository on GitHub. I’ll write a post going into more detail later, but briefly, it’s a collection of git branches where each branch contains a helper function or provides an example usage or pattern.

- Tracking down flash crashes

I’ve been running into Flash crashes on OS X for a while and noticed other people were in a similar situation. So to help resolve it, I started tracking down the various flash crash reports, and I’ve posted about my findings and issues that I ran into.

This seems to only affect the Flash Player 10 plugin on OS X, but it was still a bit tricky finding out what crash reports are related to this particular issue.

- There are many versions of the flash plugin

If a bug is reported with a crash signature like [@ FlashPlayer-10.6@0x4b4b39 ], watching the number of crashes for that signature go down may initially seem like something was fixed, but actually users are upgrading their version of flash and crashing at a different address. Additionally, it’s harder to see the actual number of crashes for this issue at a glance as the reports are spread across many entries.

- FlashPlayer-10.6 plugin version is missing

Adding to the issue of there being many versions, for some reason the version information for FlashPlayer-10.6 shows up in reports as 0.0.0.0. Fortunately there’s an additional debug identifier that is consistently reported for the same version of the plugin.

Below is a listing of some recent versions and debug ids:

10.2.151.49
nov 30
3CDC6F1339C791580EC31A451724F0110
10.1.102.64
nov 4
7F846A865E18B6E54DA2E5B46E7CF5B20
10.1.85.3
sep 20
392E898E2D7BCE8B02FFCE2287F7DF570
10.1.82.76
aug 10
5295F1D9A734E9FDD5350646BF2615A40
10.1.53.64
jun 10
28AEE5D0CE3E55DB5AE5787143EC0F960

I gathered these by looking through Adobe’s security bulletins to find the date and version of the new release. With the release date, I could then search for crash reports from before the release and see which reports disappeared. Then from the reports that did disappear, I can record the debug identifier to be for the new version.

- Crash reports not being submitted

Another issue that has recently been fixed was that most people running into these plugin crashes had no option to send a crash report. This was because Firefox by default runs in 64-bit mode and was unable to create a report for 32-bit plugin crashes. This means the frequency of the crashes were massively under-reported and the sparse crash data made it harder to find relevant reports.

- Improving crash-stats triaging

For this particular case, I can think of a couple features that could have made tracking down flash crashes more efficient.

Because the crash signature kept changing from version to version, I had to inspect many crashes to see if the whole stack is similar to other stacks. For one set of crashes, I was looking for AnswerNPP_Destroy in frame #8 to identify the family of crashes. Being able to search in part of the stack could also make it easier for various component teams find relevant reports.

For another set of crashes, the crash reason was always EXC_BAD_ACCESS at address 0x44c. So in addition to being able to filter by crash signature, being able to search by reason and address could have avoided needing to click through many crash signature reports.

There’s a number of bugs filed for these flash crashes like bug 590955, bug 572134, and bug 617469. I’m still not sure if it’s an issue with OOPP or a bug in the plugin, so it’s hard to say if flash will stop crashing by a new Firefox beta release or a plugin update. But just as a heads up, getting the latest Flash Player 10.2(.151.49) beta or Firefox 4 beta8 won’t fix these crashes.

In particular, doing a 3-finger swipe upwards no longer brings you to the top of the page. Some people have pointed to about:config to change the preferences to switch back to the old behavior. But if that sounds too complex, you can just install an add-on to do the dirty work for you. Just click the following install link, and you’re ready to swipe! No need to restart.

Install Swipe Top [addons.mozilla.org]: Swipe up to scroll to the top of the page (and down to the end).

I’ve also made another related add-on that changes the default behavior of swiping right and left, so instead of going forwards and backwards in the current tab’s history, it’ll switch tabs.

Install Swipe Tabs [addons.mozilla.org]: Swipe right to switch to the next tab (and left to the previous).

For both these add-ons, you can install them and try them immediately without restarting Firefox. If you want to get to the original Panorama and navigation behavior, just hold the “command” key while swiping. Or you can just disable or uninstall the add-on to get the original behavior as well without restarting.

If you’re interested in how I wrote the add-ons, you can check out the source for Swipe Top [github.com] and Swipe Tabs [github.com].

If you’re already on the bleeding edge running a Firefox nightly build [nightly.mozilla.org], you can install Instant Preview.

With this add-on, Firefox will start loading pages highlighted in the location bar suggestions in place of the current tab. This means you can type a letter and press Down to start viewing that page. From there you can press Return to make the preview turn into a persistent tab. Alternatively, you can press Esc to get rid of the preview if you just needed to glance at the page. So if you do end up selecting the page, it might already be done loading and ready for you to use!

This works even better if you install Speak Words, so that when you type a single letter, not only will the rest of the word get filled in, it’ll automatically highlight the first entry resulting in the page being loaded immediately. For now you’ll need to install both these restartless add-ons separately, but I’m working on a way to simplify this so you just need to install one to automatically get these new features.

Don’t forget to check out my Video Preview of Instant-like Search and install it!

Video formats: webm, ogv, mov

Transcript:

Let’s say I want to go to Planet Mozilla, so I start typing out “planet”, and before I even finish typing it out, the page has loaded over the current tab. This could be useful to take a quick peek at a page like xkcd, and then hit <esc> to return to where I left off.

Combining this with smart bookmark keywords, I can type “g” followed by some word, and it’s almost like Google Instant search. But this works for other search engines like Bing.. or even Wikipedia. As long as the site returns the page fast enough, it already feels pretty good.

Finding a page by matching the title

To help people speak words and get to the pages even faster, I’ve written an add-on, Speak Words, that will fill in the rest of the word as you type in the location bar. Similar to how Find Suggest uses words from the current page as suggestions, this add-on will look for words that you’ve previously typed into the location bar for its dictionary.

In the example above, I’ve typed “r” and the add-on has filled in the rest of the word for “reader” and searched for that word in the location bar. I can now just press <Return> to go to that page. Just 2 key strokes, and I’m where I want to be!

Immediate suggestions for new words as you type

Because the add-on gives immediate feedback on what word it’s using, you can figure out what’s the fewest number of keys you need to press to get to the site you want. Before, I would probably type “bank” or “bugz,” but now I see that I can just type “b” and “bu” instead. Also if you do type words from a site’s domain, the add-on will also help fill in the rest of the word for you as shown above.

The suggested words are based on the adaptive learning of the location bar and previously-typed domains. So your suggestions will be different from mine, and instead it’ll show you the words that you’ll likely to type in anyway, except now you don’t need to type out the whole word.

Try out Speak Words if you’re running a recent Firefox 4 beta [mozilla.com]. It’s a restartless add-on, so you can make Firefox even snappier immediately!

Looking forwards in terms of improving search in Firefox, there’s now dictionaries for word suggestions for each type of search: search engine suggestions for the search bar, in-page words for find, and key words for history. While the actual dictionary for each might need to be tweaked, it’ll be interesting to see if the search interfaces can be combined and streamlined while still helping the user with relevant suggestions and results.

Today I’ve quickly hacked together an initial prototype that helps you find words on a page. Instead of typing letters into the find box only to end up getting a “Phrase not found” message, the find bar will now show suggestions of words that will match on the page as you type. The find bar will only let you find words that are on the page anyway, so why not use those available words to guide the user?

Suggestion of words from the current page (buttons removed to fit screenshot)

This is similar to how mobile phones will suggest words based on the letters you’ve entered so far. Except instead of showing possible words from the dictionary, the find bar will only show words from a custom dictionary.

You can try out this feature by installing Find Suggest. It’s a restartless add-on that runs on recent Firefox 4 betas [mozilla.com], so you can start playing around with it immediately.

This is a quick prototype, so you can only fill in the suggestions by clicking on them. Ideally there would be some keyboard mechanism to fill in the suggestion such as hitting <Tab> to fill in the common prefix like on the command line. But even with the limited functionality, it’s a useful guide to quickly see what words will match on the page without having to type them out.

• Users get confused doing Tools -> Error Console -> Paste -> Evaluate
• Users might not copy/paste correctly or perhaps the code got wrapped oddly
• Javascript version seems to be 1.6, so let needs to be replaced with var, etc.
• Scripts are heavily GCed, so modules are imported to attach objects to keep them alive
• Everything needs to be on one line, so beware of any lines with // comments!
• Console output is html-like and strips tags and empty output leading to confusion

One additional drawback in Firefox 4 is the Error Console is now disabled by default, so having users first go to about:config and toggling devtools.errorconsole.enabled to true is an extra step where users can get lost. (Don’t forget about the click-through warning page! ) Additionally, I believe enabling the Error Console requires a restart, so debugging a live instance is troublesome unless the problem is easily reproduced.

New preference to enable the Error Console (under the Tools menu)

Fortunately, Firefox 4 comes with restartless add-ons! You can just package up an add-on with two files: bootstrap.js and install.rdf, with the relevant code running from the startup() function. It’s simpler for users to try out as it looks like any other add-on install, so just point to the .xpi and click Install.

Just make sure that if you want the code to only run once, have the add-on uninstall itself after running. Otherwise it’ll be like any other add-on that runs when Firefox starts.

Code snippets to for one-time scripts and easy reloading of scripts

Another neat trick for reloading or running an updated script is having the add-on auto-enable itself when it’s disabled. I can now just make changes to the files and click Disable once from about:addons, and it’ll automatically reload itself instead of needing to click Enable. Also because now I can just edit the file and not need to copy/paste into Error Console, I can easily track my changes with revision control software.

I’ve provided the bootstrap.js and install.rdf files needed for this simple restartless add-on. From there you just need to:

1. Delete one of the auto-uninstall or auto-enable snippets from bootstrap.js
2. Add in the code you want to run inside startup() of bootstrap.js
3. Package up the files into an xpi: zip restartless.xpi bootstrap.js install.rdf
4. Distribute/install restartless.xpi

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?

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 ). 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.

For an add-on to provide a new account type, it needs to be able to tell Firefox what saved accounts are available and how to connect to them. These might need to read data from disk and/or network; or perhaps request more information from the user like a 1-time code sent over SMS. For Firefox to support these more-complex interactions, it can’t assume that a method implemented by the add-on can return a value immediately.

Asking for additional information to connect to a banking site

In this particular mockup, the site has told Firefox not to use the basic username-password account type but instead to use an account type that asks for more information. Here, an add-on has already saved the username/password and doesn’t to ask for them, but it can’t immediately connect without asking for more information, so it tells Firefox to show this popup. With the async. API, the add-on can later tell Firefox that it has finished the connect process.

The second reason for going async. overlaps with the first of supporting add-ons; Account Manager and account types need to talk over the network to other machines. These requests can take more than just a few milliseconds, so blocking the rest of Firefox when you click on the “Sign in” button using a synchronous request would be bad. In the case of finding the account status, Firefox might need to make requests for any or all of host-meta, AMCD and the session status.

The Password Manager API in Firefox happens to be synchronous—as are many other interfaces in Firefox. Converting it to be asynchronous for use in the username/password account type was fairly simple, but there’s a couple things to keep in mind: when the work is done and when the result is given.

Implementing the async. interface with the synchronous Password Manager

Here, we’ve made the call to savedAccounts immediately do the work of finding the logins, so this means the caller might have to wait before the asynchronous savedAccounts call returns. We could have just as easily delayed this work to run after the function returns by moving the logic into the async function call, but one needs to be aware that if the arguments are live objects, the contents might change by the time async triggers the callback.

The second point of “when the result is given” is less flexible. The function above could have been written to just call onComplete(accounts) immediately without the async wrapper, but that could break the caller as the implementation is no longer truly asynchronous. The caller would stop working if code is supposed to execute after the call to savedAccounts but before the call to continuation, onComplete.

Trivial example of how non-async. implementations could break

For web developers, implementing async is pretty simple as the global window object has setTimeout. So one implementation could look like function async(callback) setTimeout(callback, 0);

Making the choice of having the APIs be asynchronous does have some drawbacks in terms of code structure. Any function that eventually calls an async. function will be forced to take a callback as well, and if it needs to call multiple async. functions, the logic needs to be broken up into multiple callbacks. If you want to share variables across these callbacks, you’ll end up creating many nested anonymous functions (closures).

Additionally, some simple things like doing Array.reduce (fold), which visits each array item and applies a function to produce a single result, can get pretty complicated if you want to pass in an async. function. In a later post, I’ll describe a way to have asynchronous functions look like they’re synchronous so that you can avoid some of this callback craziness.

(If you already know the details and just want the download, here they are: Windows, OS X and Linux)

An icon shows up in the location bar

If you visit my site using Firefox with Account Manager, you should see something like the picture above. By default, you get a plain image indicating that the site allows you to personalize your experience. Clicking on the icon indicates to Firefox that you want to sign-in.

Firefox asking for information to Sign In (WIP graphics!)

After successfully signing in, Firefox will reload the page. Notice that in addition to the page showing I’m signed-in, Firefox also knows who I’m signed-in as and informs me from the location bar.

Firefox and the website showing my signed-in status

What’s happening is that my site tells Firefox how to sign-in, and Firefox POSTs a request to my connect page, which just does the following:

<?php // connect.php
  $_SESSION["id"] = $_POST["id"];
?>

My site also tells Firefox how to figure out what account I’m signed in as, and my site responds as so:

<?php // status.php
  if ($id = $_SESSION["id"])
    echo "active; authmethod=\"username-password-form\"; id=\"$id\"";
  else
    echo "none";
?>

As a web developer, I didn’t need to write any HTML forms with input boxes and make sure they’re styled nicely. Firefox handles all that and makes it available from any page on my site. This is useful to blend into the look-n-feel of the user’s platform whether it be Windows or OS X or other devices like phones or TVs.

As an end user, I didn’t need to search for the fields to enter my information or find a link on the page that leads to a sign-in box. I know that I can just click in the same spot that I would click to sign in for other sites to sign-in. Additionally, I know at a glance that I’m looking at a personalized site and if I’m connected to the wrong account.

Now, if I were to restart Firefox, it has already remembered that I’ve signed-in to my site before, so signing-in is even easier the second time!

Signing-in to sites you've been to

Instead of the plain image, Firefox shows “Sign in” because it can do that for me. In a single click, Firefox will talk to the site in the background and reload the page. It’s so easy! Just one click.

Additionally, if I have multiple accounts on the site, perhaps an admin account and a user account, or if multiple people use one Firefox to visit the same web site, clicking “Sign in” will provide a list of those accounts.

No typing necessary to pick an account

You can try out this version of Firefox with Account Manager on Windows (installer), Mac OS X (disk image) and Linux (tarball). This is built on top of Firefox 4 Beta 4, so it includes features like Sync and Panorama and all the HTML5 and speed improvement goodness.

If you’d like to look into the details of how my site informs Firefox how to connect and get account status, you can take a peek at my Account Management Control Document which is linked from my host-meta. From there, you can start adding support for Account Manager to your own site!

Weave Debugging Sync UI

The initial debugging sync UI is to help users get out of situations where the server might contain incorrectly encrypted data (perhaps you accidentally used two different passphrases) or some other reason your local data isn’t syncing to the weave server. So for now, you can use the buttons to wipe the server data, wipe local data and resync with the server, or wipe remote data and have them resync with the server.

Initial Weave debugging UI to control syncing

It’s kind of neat watching the local wipe clear out the bookmarks toolbar and then have it fill in with the bookmarks encrypted on the server. But don’t get too attached to the interface. We’ll be switching it to be more user friendly such as having diagrams of which way you’re syncing data (two-way sync, one way to your machine, one way to other machines) as well as being able to select which pieces of data to push out.

But this initial step is just getting the right logic to perform the various syncs. For example, I created a way to have each data engine reset their local temporary data without completely wiping out permanent data. Previously, there was just a single resetEngine method, but some engines treated that as wiping. There’s a whole set of service calls to reset and wipe the local/remote client and server now.

Weave Refactoring

The first thing I cleaned up was the syncing logic of choosing which engines to sync. Right now weave syncs all engines, but some previous version used to sync engines by thresholds. The threshold syncing was actually handled by a separate code path, but it did pretty much the same thing as a full sync. So I just combined the two and cleaned up the callers and fixed some divergences in the code. There were potential bugs in the unused threshold sync because we’ve only been updating the full sync code.

Another refactoring was deciding if a sync should run and if we should schedule a sync. Both of these were basically checking a number of statuses such as logged in, enabled, etc.; so I just combined them to simplify the logic for the two. This made me feel much cleaner about making weave not try syncing when in private browsing or offline — I only had to make changes to the unified “check sync” logic instead of duplicating code all over the place.

One last cleanup I got in was switching code to use the lazy services attached to the Weave.Svc object. Instead of having each object differently implementing their own lazy services, they could just re-use the lazy property that might already have gotten the service. Some of the original code checked if a “private” instance existed and returned that, others had a getter define another getter with a local closure to capture the instance, and some just grabbed the service directly. Instead of having all these class ids and interfaces scattered throughout the code, the centralized code can efficiently implement laziness as well as simplify debugging.


New Tab Text View

After looking through the initial feedback for the new tab page, Aza made a text-focused view for the new tab page, which got rid of all the thumbnails that were slow and not too useful. This was a whole separate page that had its own logic, but I cleaned things up by refactoring the shared data logic between the thumbnail and text views.

It turns out this is a good way to figure out how code should be structured to be reusable with different views. For example, the code for picking out which sites to show as well as their accompanying feeds were already in their own separate modules, but various clean-up code that could be used by both could be pushed to the data source as well.

However, I did run into an issue moving <script> code into a Cu.import module. Apparently plain unicode characters work just fine in the script code, but when imported, they need to be escaped like \u2013 for –. So I just escaped them when sharing the subtitle trimming code between the two views.

New Tab Customization

Another feature added recently was the ability to persist site removal. A lot of people want to customize their site list, so now you can just keep removing sites until you find the one you want. This actually ended up being fairly simple to implement as the back-end site storage just kept an array of sites to use, so modifying that structure allowed it to persist across new tabs.

Also, by reusing that site storage, we allow configuration of the number of feeds (or none) for each site, and that gets persisted across new tabs. With all this data in that shared storage, it shouldn’t be hard to get cross-browser data. All that needs to be done is to write the data out to disk, perhaps in a preference. Javascript now has a handy JSON object to stringify and parse json objects, so writing and reading the array is easy.

New Tab Performance

One last thing in terms of performance is that both sites and feeds are being prefetched on browser load. This is done asynchronously (yay Shawn!) so it doesn’t block the main thread which handles drawing and UI. The sites fetching code needed to be switched to use async queries, but that just needed some code restructuring. Instead of using a return value right away, pass the site getter a callback that gives the result. So for prefetching, the callback is used to trigger yet another async query, but this time for feeds.

One big change is that we’ve switched to a more text-focused view. Instead of having gray thumbnails that aren’t too recognizable to you, we focus more on the site’s icon that you normally see in tabs. We can have a cleaner display for the site’s name yet still make it easy to click (basically anywhere) in that site’s box. Also, instead of being overloaded by too many feeds you don’t want, the default is now 3 and there’s more breathing room.

New text-based view for new tabs with customizations on the side

Another big change is customizability. A lot of people want to be able to reorder the list and get rid of things they don’t want. The initial release allowed you to drag things up and down, but it didn’t save that ordering, but now it does (for just the current browsing session, for now). You can now remove sites by clicking the edit text then de-selecting the checkbox (where the site’s icon would be) then confirming to remove the site.

Some people didn’t really want feeds for some sites, but for other sites, the feeds were very useful. You can now get rid of feeds by clicking edit and dropping the number of items shown to 0. (Just pretend the 2 radio buttons were actually buttons with “-” and “+”… ) After adjusting the length to what you want, you can click on save.

As a bonus for comparison, you can hit the asterisk (∗) at the bottom corner of the screen to switch to the old thumbnail view. It uses the same data as the text version, so customizations you do on the text view will show up on the thumbnail view. It’ll even remember which view you used last, so next time you open a tab, it’ll show the right one. But just to note, we’re focusing more on the text view right now, so there will be features missing from the thumbnail view.

But we’re still focusing on speed and streamlining the behavior so that you don’t need to do much customization after using it for a bit. We now prefetch sites and their feeds, so the new tab opens up much faster, and the feeds will automatically get the newest information from time to time. Also, some have asked to be able to customize which feeds are shown, but if we can pick the right feed all the time, that saves the extra step.

For the official Mozilla Labs post by Aza, check out Firefox New Tab: Next Iteration [labs.mozilla.com]. Please try out the latest version of About:Tab [people.mozilla.com] and keep giving useful feedback.

Keep track of comments, bug fixes, code commits at Planet New Tab! [newtab.agadak.net]

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.

With this add-on, you get a listing of sites you frequently visit with thumbnails and feed items instead of a blank white page on opening a new tab. These sites are shown along the far-right edge of the page to avoid interrupting your behavior if you just want to type in the site you want to go to.

You don’t need to manually bookmark sites or pick pages or even subscribe to feeds! The new tab page is smart enough to figure out which sites you frequently go to and shows related items like feeds.

Easily access your frequently visited sites along with their feed items

The sites are listed along the right edge of the page to be visible but not glaring. That’s why the thumbnails are shown in gray so that flashy sites don’t overpower the simple look. Both the thumbnail and text are faded gray until you put your mouse pointer over it to interact with it.

The page additionally will provide navigation options based on your behavior. If you’ve copied an address to map, you’ll be able easily get to the map by clicking on a link from the new tab page. Additionally, if you’ve recently closed a tab and want to get back to it, you can restore it with a single click.

Behavior-based navigation suggests actions that you'll likely want

Check out the official Mozilla Labs post describing the ideas behind the New Tab Page [labs.mozilla.com]. As pointed out there, the main themes behind the new tab page were were No Configuration, Streamlined, and Polite. Thanks everyone for the early feedback, and please continue to provide comments, criticisms, and suggestions [labs.mozilla.com].

This is an early prototype that Dan Mills initially started coding less than a week ago, but it’s pretty functional already as it has drawn from existing projects like Atul Varma’s Ambient News [toolness.com] and my Auto Dial. You can follow the development of this prototype [wiki.mozilla.org] to see what’s going on or even contribute.

For those using my Auto Dial add-on, you can easily uninstall it and update to About:Tab [people.mozilla.com] from Tools -> Add-ons. About:Tab provides more functionality with behavior-based navigation and feed items as well as a cleaner interface with thumbnails.

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!

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.

Google's account troubleshooter

Why do websites have sign-in forms anyway?

I suppose the site just wants to ask “who are You?” Signing in lets you personalize your experience on the site. Let You get to the stuff You want. That’s just some of the benefits for the user.

For the website, it wants to make sure it only gives your stuff to you and not some random person that’s also using the site. One way to ensure that is to “challenge” you by making you answer something that hopefully only you know.. like your username and password.

But what if the browser you’re using already knows that you are You?

Instead of challenging You to see if you happen to remember your username and password, the website could challenge your browser to prove that it’s You. Now you don’t need to worry about forgetting your password or username. You don’t need to worry about having a weak password either because computers are good at remembering and calculating complex stuff.

But that’s not all! One very useful aspect is that you wouldn’t even need to sign in to websites anymore!

The challenges that site asks to prove that you’re You can be made in a way that only your web client can answer them. So when you go back to the website, it already knows who you are, and nobody else can pretend to be you. And this is only if you let your client tell the site.

Even better is that you don’t even need to create an account on the website!

You can start using and personalizing your experience on a site without first going through the user creation process. Because the site knows that only you can be You, you can focus on getting a better experience now and later go through the nitty gritty details of providing a name, contact information, etc. if necessary.

Use the site first, create an account later

For example, if you’re using a site to purchase items, e.g., stuff for a house or even a house, you could make notes on items without first creating an account. Next time you visit, the site already knows it’s You, and this is without being required to put any personal information. The site might eventually want your email address to send you notification that this item just got cheaper by 50%, but that’s up to you.

But what about privacy?

Just because one site knows you’re You doesn’t mean another site can know that. You could choose which sites your browser accepts these identification challenges, and if it doesn’t respond, the site can’t figure out who you are any better than how things are now.

Additionally, because computers are good at doing menial things like tracking lots of numbers, the way it answers challenges can be different for each site. So if you took a bad approach to this problem by just having the web client make some identification number, the web client could give a different identification number to each site instead of sharing the same number. That’s just to get a crude feel of how a client can maintain your privacy across sites, but real implementations would have much more complex challenges.

Go Phish?

If you happen to stumble upon a phishing site that didn’t automatically get blocked, there’s a lot more red flags that will be going off for the user. “Why do I need to all of a sudden sign into this site?” “Uhh.. how do I even sign in.. my client handles all that for me..”

Just one of the tasks for the Identity Center

If all this was part of a cloud-based web client like EdBrowser, you can get this great experience no matter where you go. As long as you first get your information from the cloud to the client you’re using, your client will have enough information to answer the challenges to prove that you’re You, even if you’re at another computer like a mobile device.

The EdBrowser first simplifies Going Places by getting you there in a single click, and now you can make use of websites without needing to type in a username/email and password! There’s fewer and fewer reasons to touch the keyboard just to get to your actual goal — to use the site!

How would you go to a website from this screen?

Hopefully if you’ve been using Firefox for a while, you’ve found out that it is smart enough to show the site you want after typing just a single letter in the location bar. Firefox remembers which sites you go to frequently and what you’ve typed before, so it can better suggest the page you want — one reason why people say it’s so awesome. And if you’ve installed Enter Selects [addons.mozilla.org], you can just hit [enter] to go to the first result.

There’s 3 or 4 steps involved here:

1. Getting to the location bar (click it or use the keyboard shortcut)
2. Typing what you want (a single letter or more)
3. Finding the result from the list (optional presses of [down] or [tab])
4. Selecting the page (hit [enter] or click)

There are plenty more ways to get to the page you want:

• Click the search icon in the top-right box and then search — ~6 steps
• Search from the default home page — ~5 steps
• Search from the top-right search box — ~5 steps
• Search from bookmarks sidebar — ~4 steps *
• Open from a new tab (with a smart new tab page) — ~3 steps
• Select from the smart bookmarks drop-down — ~2 steps
• Select a page from the location bar drop-down — ~2 steps
• Open from bookmarks sidebar — ~1 step *
• Click a bookmark from bookmarks toolbar — ~1 step *

I put a * next to the ones using bookmarks as you have to first bookmark a site and organize it into folders or put them onto the toolbar. So there’s some initial cost for setting them up, but it can pay off in the long run — just a single step to get to the site in the common case.

There are many ways to get to a site with varying number of steps

It’s not bad that there are many different ways to get at the same goal. Each way has its own benefits and drawbacks. For example, going to a bookmark is very simple (assuming it’s visible and clickable), but you need to have bookmarked a page beforehand, and going to a new site from a bookmark could be tricky. Additionally, you need to sacrifice screen space for the sidebar or the toolbar.

The main metric I’m looking at for these different ways is the number of user actions required to get back to a site. Just think about how many times you go to the same site over and over again. You might go to a number of sites frequently and others not as frequently, but you still revisit them more than a random site you’ve never heard of.

And don’t forget that others might have more difficulty than you when using a mouse or keyboard. Even if you only need to type a single letter to find the site you want, finding the right one key to press on the keyboard can be an ordeal in itself.

So ideally we make this common behavior very easy to do. At most one click is needed as we’ve seen with bookmarks. But bookmarks are “difficult” to work with as it requires extra effort from the user.

The idea behind EdBrowser’s Site Launcher comes from this goal of streamlining the interface to allow the user do what s/he wants — interact with the site – not the browser.

Get to where you want to be with a single click

Instead of having to manually bookmark sites and organize them to be accessible, the Site Launcher automatically figures out which pages you’ve been going to frequently — you kept typing them in over and over again. You can even drag the current site from the “temporary” right side and pin it somewhere on the left because you want to go back to it.

As you get more and more sites on the Site Launcher, there’s less and less need to type in the site you want. This means all that space currently used for some text input like the location bar isn’t as necessary any more.

But just because this text input gets smaller doesn’t mean you can’t type-to-get-to-the-site. In fact, having sites on the Site Launcher can streamline the keyboard interface even more. Searching from that input box can first prefer pages contained in the Site Launcher. This includes your open tabs, main pages of the websites, as well as pages you frequently visit; it would even include recently closed tabs.

A brand new shiny web client with buttons and boxes that's better than foxes!

Okay okay. I’m not actually making a web client of my own, but if I had a lot of time and the right infrastructure, it would probably look like the picture above. (I suppose I do have a lot of time seeing that I’m unemployed. But that does have various benefits.. no going to classes, no studying for exams, no paying income tax to blow up then rebuild bridges.. And who would want to use something called EdBrowser?!)

I’ll just go in left-to-right order describing what you can see (and don’t see) in my mock-up:

1. Identity Center
2. Site Launcher
3. Text Input
4. Web Content

Identity Center

First off, we have something new here — the web client knows who you are and lets you know who it thinks you are. (If your name isn’t shown, you’ll want to “log in” so your experience is personalized for you. Everything described further down can be stored as part of your account.)

When the client knows who you are, it makes it easy for sites to find out that it’s you if you let the site know. Now you won’t need to fiddle with logins and passwords for “simple” sites like forums. Additionally, sites can restrict sensitive data (bank accounts, emails, etc.) and require you to give the web client a password. When you do so, the client will send the server an impossible to guess “password”, which it set up earlier, and now you don’t need to worry about internet hackers guessing your bank password.

There’s a lot more functionality for this “Identity Center,” but because I made it green and ugly, I’ll talk about it at the end.

Site Launcher

You might be wondering wheres the tab bar, and here it is! Kinda. You can initially think of this area as a combination of the bookmarks bar, tab bar, and history drop-down menu.

I’ve mentioned in some other post that even with a smart new-tab page, you still need to open a new tab then find the page you want to open — 2 clicks. Similar two steps if you use the drop-down menu. And bookmarks… ew.. at least the drop-down menu automatically shows the sites you frequently use instead of manually bookmarking sites.

What you really want to do is just get to a site you frequently visit. So let’s just put those sites in an easy-to-find place.. in the Site Launcher! The web client knows which sites you use frequently, and it will automatically populate the area with the icon for that site. Now when you want to open the site in a new tab, you just click on the icon. Done.

But that’s not all! When you move your pointer over the icons, it’ll show you titles and thumbnails of all your open “tabs” that share that same icon. It will also show thumbnails of pages that you frequently go to on that site. This means no more loading the site’s home page then clicking through to the actual page you want. It shows up right there – accessible with a single click.

And as a bonus, you would be able to search the listing of tabs and pages you frequently visit to restrict your searches to just that one site.

Opened sites, unopened sites, trash and active tabs

The Site Launcher has 3 main components:

1. Sites you commonly use
2. Trash for removed sites
3. New/temporary sites

When you visit a site not in the Site Launcher, it shows up towards the right side — to the right of the dot. If you want to “pin” the site, just drag it to the left of the dot. You can close that site just by dragging it to the trash or any other normal way you would close a “tab.”

While the trash isn’t really a site, you can still hover over it just like any other site’s icon. Except now it shows you thumbnails of sites you’ve recently closed and might want to reopen. “Undo” is such a great feature!

The dot is there for you to drag if you want more space for sites to automatically fill in to the left side. But hey, you’ve got a lot of space now that there’s just the Identity Center, Site Launcher, and some small Text Input box…

Text Input

Not much to explain here. Just type what you want to do. You can execute commands or search your history and/or the web. You could just put text to store there if you wanted. I suppose you could type a URL, but why do that when you’ve got the Site Launcher!

But about the location bar.. There’s nothing showing URLs anywhere. Not in this text box or when showing sites you might want to launch — those are just titles and thumbnails. (Wait! Didn’t this guy make the AwesomeBar awesome?! Oh well.. Okay fine. You can still get to the current URL and edit it, but it’s not shown in the main interface.)

I lied. It’s not really just a text box for input. When you click on the “text box,” it also opens up bigger box in the middle of the screen, so when you type it shows up in both places. This box will show the results of what you’ve typed in. So it could be a map of an address you’ve selected or pages that you might want to go to. And after you hit enter for the command or search, the input box clears itself.

Web Content

Content is king! Lots of space for it here with just little partitioned off to the web client.

So I’ve already talked about web sites knowing who you are, and now you won’t need to keep logging into sites before you use them. But there’s more websites can do with information if you give them access!

Share your history to find great deals (but no Wii will be that cheap...)

If I’ve given Amazon.com access to my Target.com history, the next time I visit, the site can figure out what items I’ve been looking at and hopefully offer me a better deal. No need for me to manually search for the same item across multiple websites.

Another example would be sharing my digg.com history with a news aggregator site like Google News. It can know that I dugg an article and show me news stories related. Additionally Google could dig deeper and find when the original article was submitted or when I dugg it and only show news that has happened or updated since those times.

Identity Center

Back to the ugly green button. It actually comes in different colors like red and gray. It would also have a different emphasis state when the site wants to get at more of your data (but hopefully it’s not an annoying animation..)

For example, when you first visit a site, the button will appear gray because you haven’t given the site any access. It would then try to get your attention, and pointing your cursor at it would show a message like “Site ABC would like to know who you are. 40% of your friends have granted access; 3% deny. Grant or Deny?” Granting access could be limited to just the site knowing that if you “log in” to your web client from somewhere else, it’ll know it’s you again. This can be done without ever giving away your name or other personal information.

Having the web client know about your social network is nice, but re-entering all your information to a web client is a pain. You already have a lot of information on a number of websites, so let’s collect that. When you visit certain sites, the Identity Center could let you know that you can extract data from those sites and securely store it on your profile. Then you can share that information with other sites you visit if you choose to do so.

Crude mock-up of attempting to grab attention

Other situations where the Identity Center button might want your attention is if the site wants to know more than just who you are. Clicking the button could show a list of sites that you might have history for. If you do have history, you can preview what information is sent to the site as well as visit the sites that you haven’t been to before.

If Amazon.com is asking for your visit history of competitor’s websites, they’re also giving away which competitors they’re interested in. You could then navigate to new sites that you didn’t even know about. (Or just visit the ones where your friends have also visited and granted access.)

There’s an endless combination of what can be done with having your data accessible online while selectively giving out certain portions to certain sites. Also, there’s plenty of interesting personal data that already exists on some sites, so you could unleash so much potential if it was easy to make that information available.

Do you have suggestions to streamline user tasks in this new web client?

So that’s a quick overview of some parts of my imaginary EdBrowser. There’s plenty more that I’ve thought about but am currently too tired to write up. But even if this web client doesn’t exist yet, the technologies needed to make something like this are coming in. There’s the AwesomeBar as part of Places that pushed towards adaptive behaviors and Ubiquity for new interfaces for “doing stuff.” And there’s Weave for securely pushing data to the cloud and letting the user selectively open it up.

The user is the focus of attention here, and making the experience better and more streamlined is the goal. The user isn’t just passively browsing the web anymore as s/he gets to leverage the web client to easily get at whatever is desired. (So actually.. User is King! or Queen! )

At first I suggested using the new “Forget About This Site” feature where you can select a page from your History Sidebar and choose to forget everything (history, cookies, etc) about that site. Doing this would prevent any of those pages from showing up in the location bar because you would have no history for that site.

Quick way to remove a site from the location bar

Unfortunately, that requires the user to actively clear the site from his/her history. (Perhaps Firefox could automatically do that for the user in a privacy-aware manner…)

Josh then had a question regarding userChrome. Since Firefox 3 handles all sorts of fancy CSS 3 selectors including substring matching in attributes with *=, I figured it would be fairly simple to match the url or title of a location bar result and hide it.

This technique works well if you don’t mind leaving trails of your privacy hiding in plain sight. However, I suppose the ease of taking a peek at userChrome is a quite bit more difficult than just typing in the location bar.

Hide pages that match your keyword/pattern in the URL or title

All you need to do is use your favorite way to style Firefox, e.g., editing userChrome.css in your profile’s chrome directory or through an add-on, and add a style matching the class name “autocomplete-richlistitem” as well as a selector for either the “url” or “title” attributes.

For example, if you want to block any results that have “facebook” anywhere in the URL, use the following style:
.autocomplete-richlistitem[url*="facebook"] { display: none; }

This is just a simple hack to prevent certain pages from showing up. The location bar by default tries to show the top 12 pages, but if you’re hiding pages, you might end up with no results. You can try changing the value of browser.urlbar.maxRichResults from about:config to get more results, so if any get hidden, there are others to fill in the space.

Well, maybe not as it’s a brand new add-on I’ve written that shows your home page instead of about:privatebrowsing when starting Private Browsing Mode. That’s all! Very simple.

Panic Mode works just like Private Browsing except it shows your home page

Now when your boss is walking over and you’ve got a bunch of tabs for online social networks, chatting and personal mail; just hit the shortcut for Private Browsing (Ctrl/Cmd-Shift-P), and woosh! those tabs disappear and now it looks like you’ve been busy working! Saved by Panic Mode!

Just remember that you’re now in Private Browsing, so if you hit the shortcut again, it’ll bring back the tabs you had opened. (Don’t mix up those modes! Could be dangerous if you restored those tabs as your boss is looking over your work!)

Oh, and any kind of home page works. So if you’ve set a bookmark folder to be your home page, it’ll load all those tabs when going into Panic Mode.

Try out Panic Mode Add-on [addons.mozilla.org] today!

Thanks for installing/upgrading Hide Unvisited. This latest version is only for Firefox 3.5 and leverages the built-in privacy functionality of Firefox 3.5, so you don’t even need the add-on anymore. The add-on has already automatically uninstalled itself and set the preference as described below for you. But if you want another add-on to try, check out Enter Selects — pressing enter from the location bar will now automatically go to the first result.

User Privacy has made big steps with Firefox 3.5. First off it’s very simple to clear out the last hour of online shopping, medical researching or media browsing with “Clear Recent History.” This is much smarter than wiping out your entire history or not letting Firefox track any history just to prevent some pages from showing up in the Location Bar. Another big privacy feature is Private Browsing Mode [support.mozilla.org] (Panic Mode? ), which starts a new browsing session where Firefox won’t track any history until you leave that mode.

Both these features affect the Location Bar because removing pages from your history stops you or someone else using Firefox and accidentally finding those pages when typing in the Location Bar.

One slight caveat is that by default, Firefox will suggest bookmarks from the Location Bar because you’ve added a star to the page and probably want to revisit it. This means even if you clear your browsing history, bookmarks will still show up when searching for pages.

Choose what Firefox 3.5 can suggest from the Location Bar

Firefox 3.5 adds a new drop-down menu in the Privacy view when setting your Preferences. Here you can tell Firefox to only search “History” instead of the default of “History and Bookmarks.” This means if you use a bookmark and remove traces of visiting the bookmark, it won’t show up in the Location Bar until you revisit that page you bookmarked.

On a related note of only showing pages you’ve been to, Firefox 3.5 will only suggest pages that you’ve typed in the Location Bar when clicking the drop-down button. This means the 12 sites that appear in the list are those that you frequently use to start browsing. Similarly, Auto Dial 6 has been updated to only show pages you’ve typed. These two make great ways to go back to sites that you launch from.

Two launch-points to get you started in just a couple clicks

If you want more advanced control of the Location Bar behavior, check out Firefox 3.5 Location Bar Preferences.

I’ll explain three new groups of preferences that let you..

1. Toggle suggestions on and off
2. Customize what results get shown
3. Change the matching behavior as you type

Configure Smart Location Bar's behavior from about:config

Toggle Suggestions

The first preference is fairly simple; toggle browser.urlbar.autocomplete.enabled to turn the location bar suggestions on and off. This is useful if you always want to type out the URLs you want, or if you can type a whole domain and hit enter faster than typing a single letter and having Firefox suggest the site you want.

If you’re just looking to prevent certain pages from showing up in the suggestions, there are better options available than using this sledgehammer (see below). Also, for those who have set browser.urlbar.maxRichResults to 0, -1 or something else (e.g., userChrome.css) to turn off suggestions, using this preference is better as it prevents your CPU from wasting power while searching for results that Firefox won’t show.

Customize Results

The second preference lets you make the location bar only match URLs of pages you’ve visited, similar to Firefox 2′s behavior. It’s much more powerful than just that as it also lets you restrict results to pages that you’ve 1) visited, 2) bookmarked, 3) tagged or 4) typed in addition to letting you force your search terms to match in 1) the title or 2) the URL.

You can use any combination of these filters to reduce the number of results that show up in the location bar’s suggestions. Another way to look at it is if you specify some filters, e.g., bookmarked + typed, you’re getting rid of anything that isn’t that — throw away all results that aren’t bookmarked as well as get rid of pages that you’ve never typed in the location bar.

The way you set these filters in browser.urlbar.default.behavior is slightly tricky if you’re not familiar with “bitmaps.” They’re not too complicated to deal with, but you will have to do some simple addition in your head. The way things work is each filter is given a number value, and to figure out what number to set for the preference, just add up the values of each filter you want.

If you want the location bar to only match URLs of pages you’ve visited like Firefox 2, set browser.urlbar.default.behavior to 17 (1 for visited pages + 16 for URLs).

Similarly, if you want to additionally restrict results to pages you’ve typed in, add in an extra 32 for “typed” — 49 for matching URLs of typed, visited pages. So for those who have used browser.urlbar.matchOnlyTyped in the past, you’ll probably want to add 32 to any other filters you want.

The whole set of values for each filter are as follows:

• 1: visited
• 2: bookmarked
• 4: tagged
• 8: match title
• 16: match URL
• 32: typed

Filter On-Demand

The last group of preferences are very related to the previous preference, and I’ve introduced their functionality in my post on Firefox 3.5 Restricts, Matches, Keywords.

Basically they do the same thing as the previous preference except you type in a special character to turn on a filter as you’re searching from the location bar. This lets you pick and choose when you want the filters to be in effect instead of always being on.

The default symbols for these “on-demand” filters are as follows:

• ^: browser.urlbar.restrict.history
• *: browser.urlbar.restrict.bookmark
• +: browser.urlbar.restrict.tag
• ~: browser.urlbar.restrict.typed
• #: browser.urlbar.match.title
• @: browser.urlbar.match.url

One big difference from what I described in the earlier post is the handling of empty filters. Setting these restrict/match preferences’ special symbols to nothing prevents you from (accidentally) activating that filter dynamically. However, you can still set the default.behavior to use that filter automatically.

1) In Firefox 3.1, copy the following block of code and paste it into the “Code:” line in the Error Console (cmd-shift-J) then hit enter:

C=Components;d=C.classes['@mozilla.org/browser/nav-history-service;1'].getService(C.interfaces.nsPIPlacesDatabase).DBConnection;for(o=[],c=97;c<123;c++){h=String.fromCharCode(c);q=d.createStatement('SELECT title t, url u FROM moz_inputhistory JOIN moz_places ON id=place_id WHERE input LIKE \''+h+'%\' ORDER BY use_count DESC LIMIT 1');if(q.step())o.push(['<b>',h,'</b>: <a href="',q.row.u,'">',q.row.t,'</a>'].join(''))}open('data:text/html,'+o.join('<br/>\n'))

2) View source to copy the generated html to put in your blog. (I’ve added emphasis for what I was trying to match.)

a: Amazon.com: Online Shopping for Electronics, Apparel, Computers, Books, DVDs & more
b: Bank of America | Home | Personal
c: Capital One Online Banking | Capital One Online Banking
d: Digg – All News, Videos, & Images
e: edilee
f: Firefox Builds • mozillaZine Forums
g: Video Game Cheats, Reviews, FAQs, Message Boards, and More – GameFAQs
h: Hulu – House
i: The Internet Movie Database (IMDb)
j: Joystiq
k: Kotaku, the Gamer’s Guide
l: The LLVMdev November 2008 Archive by thread
m: Mac Rumors: Apple Mac Rumors and News You Care About
n: Gaming Discussion – NeoGAF
o: OrderStatus
p: Planet Mozilla
q: PhD Qualifying Examination | University of Illinois at Urbana-Champaign
r: Google Reader
s: JavaScript Shell 1.4
t: tinderbox: Firefox
u: Gmail – Search results – edilee@gmail.com (unread)
v: Apple – Support – Discussions – New MacBook connected to external VGA …
w: Firefox3.1/StatusMeetings – MozillaWiki
x: xkcd – A Webcomic – Drapes
y: Bug 465076 – Yet another Ctrl+Tab / All Tabs design revision
z: Craig Zilles, Department of Computer Sciences

The pages listed here are those that I visit frequently, so it’s not the best way to see the word searching ability of the location bar; however, it’s interesting to see that all but one site matches on the title. It’s also neat to know that I only need to type a single letter and hit enter [addons.mozilla.org] to go to those sites.

I knew iPhoto supported 3-finger swipes to switch between pictures, so I figured I should file a bug so Firefox could do something similar to switch tabs. Lo and behold, there’s already a bug filed and resolved fixed since April! Three-finger navigation gestures on MacBook Pro trackpads should be recognized [bugzilla.mozilla.org]

Wait a minute.. that’s Camino! But it didn’t take long to find two related bugs: Core: widget/event-detection support for multi-touch trackpad gestures and Firefox: Implementation of Multi-Touch Gestures on Mac OS X [bugzilla.mozilla.org].

And even better is that both bugs have patches already reviewed or in the process of getting reviewed. The bugs were inactive for a few months, but Tom Dyas appeared out of nowhere (AFAICT) and started submitting patches with the help of Camino, Mac, DOM guys.

Earlier I took the Firefox patch and tweaked it slightly to conform better to sdwilsh style standards and added various refactoring. And now I’ve tossed those pair of patches up on the try-server so people can touch Firefox with a new set of gestures.

A quick detour for those not familiar with the multi-touch gestures.. The most basic multi-touch gesture is the 2-finger scroll which has been around for over 3 years (my iBook had it), and it lets you scroll through pages up/down/left/right/diagonally. Recently added is the 3-finger “swipe” where you place 3 fingers on the trackpad and move them in any direction like the 2-finger scroll. A couple other iPhone-inspired gestures are the “pinch” (2 fingers moving towards/away from each other) and the “twist” (2 fingers rotating).

Note! The following gestures are totally tentative and subject to change, and I’m not sure if they’ll even make it into Firefox 3.1. (From what I quickly gathered, the gestures interface was reverse engineered from some private Apple API, so things might change at any time!) You have been warned!

• Swipe Left: Go back in history [bonus! hold Cmd to open it in a tab]
• Swipe Right: Go forwards in history
• Swipe Up: Return to top of page
• Swipe Down: End of page
• Pinch Together: Zoom out
• Pinch Apart: Zoom in
• Twist Right: Next tab
• Twist Left: Previous tab

Personally, the biggest benefit is the ease of going to the very next tab with just the touchpad. No need to use keyboard shortcuts like cmd-alt-right or fn-ctrl-down or cmd-tab#. Rotating to the right doesn’t just go to the next tab because if you keep twisting right, you’ll go to the next one and the next one. You could think of it as turning a dial to pick the tab you want. And of course, turning the dial back in the same motion switches back to the previous tab.

So if all that sounds interesting and you want to try, make sure you have one of these machines before downloading:

• MacBook Pro from this year (either early-2008 model or the new late-2008 ones)
• MacBook Air (both models from 2008)
• MacBook from late 2008 (the new aluminum ones)

Firefox 3.1 Beta 2 “pre” with Multi-Touch Gestures – OS X only [build.mozilla.org]
Edit: This feature has been in “trunk” since Oct. 23. Firefox 3.1 will have this feature, and the upcoming milestone, Firefox 3.1 Beta 2, will have it. If you want to grab a version now, you can use a nightly build [ftp.mozilla.org].

Thanks again Tom Dyas for working on this feature!

The add-on creates a page that fills up the screen with links to your frequently visited pages with the most frequently visited ones at the top being the easiest to click. As you go further down in the list, the links become smaller for the pages that you less frequently visit.

Quick access to frequently visited pages on new tabs (Ctrl/Cmd-T) (larger)

The Auto Dial page shows up every time you open a new tab. So after you hit Ctrl/Cmd-T, you can type into the Smart Location Bar as usual to search through your history as well as easily access your frequently visited pages with a click. With the Auto Dial page, you can click any of the pages like a normal link (middle-click or Ctrl/Cmd-click to open in a tab).

Other features in the current version include letting you to type the page’s number to jump right to it (hover over a link to see its number), moving selection with the keyboard and stripping off “http://” from URLs. There’s also a collection of about:config preferences to tweak to your liking: how many pages from the same site to have, how big the largest button should be, how fast the number of buttons grows, and how long you get to type the page number.

Auto Dial Add-on [addons.mozilla.org]

“.. adds incredible functionality. It’s like Active desktop for the browser.” “i love it! instantly my became my first useful home page” – Michael, zac

Thanks again for the feedback through email, my blog, IRC, and AMO.

Unfortunately, sometimes Gmail doesn’t know that you’re typing — keyboard commands all of a sudden stop working.

I’ve noticed this a lot recently when I use [alt]-[enter] to open a new tab from the location bar. This often happens when I’m reading a bugmail and want to see what a bug is, so I copy/paste the bug number and type “bug 395739″ into the location bar and hit [alt]-[enter] so that the keyword search opens the page in a new tab. After switching back to the Gmail tab, I can no longer press “u” to return to the message list; instead, find-as-you-type finds a random link containing “u”.

Adding labels to bug messages just by typing

So to address this issue, I’ve written a simple Greasemonkey script that fixes the problem that I’ve been running into. It even lets you hit [tab] from the location bar (to the search bar) to the web page and have keyboard commands working in Gmail.

If you have Greasemonkey [addons.mozilla.org] already installed, all you have to do is click the following link to install the fix:
Gmail Fix Focus [ed.agadak.net]

For those curious, the reason why this focus problem occurs is that when Firefox opens a page in a new tab, it decides to move focus from the location bar into the page. However, Gmail is made of a bunch of IFrames, so focusing the outermost-top page doesn’t send the keyboard presses to the right place.

If you want to be even more efficient, take a look at Enter Selects [addons.mozilla.org]. This add-on gets rid of the middle step for you by automatically selecting the first result when you hit enter.

Pressing enter will select the first result

If you don’t want the first result to be selected, press [esc] or [left]/[right] to close the suggestions. However, if you’re typing in a URL or editing one from the suggestions, it’s smart enough to do what you want. You can even type in a domain like “ed.agadak.net” and not worry about it automatically selecting the first result.

“I install this on every instance of FF3 I get my hands on thus saving buckets of extraneous keystrokes a day.” “Wow this just makes the AwesomeBar so much more usable.” – danhorst, pacifika [addons.mozilla.org]

Quick update on my other add-ons. The functionality of Hide Unvisited, Edit Middle, and Show Keywords have made it in to the nightly versions of Firefox 3.1, so if you’ve already got those installed, you won’t need them for the next major release.

just pressing enter

So in Firefox 3.5, there’s some new ways to change what shows up in the Smart Location Bar such as restricting results to show only your history (and not your unvisited bookmarks) or matching only in the URL instead of also in the title. Additionally, you can see your Smart Keywords queries show up in the drop down.

You can restrict the search to your history by typing “^”, or bookmarks with “*”, or tagged pages with “+”. To make what you’ve typed match only in the URL type “@”, and for title/tags only use “#”.

You can first start typing something you want to find like “mozilla”..

All results that match "mozilla"

Then realize that there’s too many results and you know it’s a page that you’ve tagged, so you restrict the results with “+”..

Restricting "mozilla" to tagged pages

Then continue narrowing the results by typing more words..

Quickly finding pages out of thousands

If you prefer the results to always restrict to history and match only in the URL, you can go to about:config and change the corresponding preferences to nothing (edit the value and delete the special character). This way you can always be only searching your visited history and not worry about matching in the title. If you’ve installed Hide Unvisited [ed.agadak.net], you can uninstall it and just change browser.urlbar.restrict.history to “” (nothing).

Preferences to change default restrict/match behavior

As with the Hide Unvisited add-on, restricting to history will only show pages that you have visited and are stored in your history. This means if you visit a bookmark, it will still show up even when restricting to history. However, you can select the entry from the location bar and hit Delete, or delete pages from the History Panel, or just Clear History to make them disappear.

If you don’t like the standard characters to enable restrict/match, you can modify the values from about:config to be whatever you want. They can be single characters, whole words, even words in other languages.

One last thing about Keywords is that you can now see what you’re going to search with a Smart Keyword Bookmark. You can even assign multiple bookmarks the same keyword so one can be the default Wikipedia search and another can use I’m Feeling Lucky [google.com]. You can uninstall Show Keywords [addons.mozilla.org] if you’re using that for Firefox 3.

Choose from multiple Smart Keyword Searches

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.