Planet Mozilla

Today TechCrunch reported on a paper describing a way to use Facebook for malicious means.  The paper describes a DDoS attack that can be done, leveraging the large number of users of an application to attack a victim site.

While this attack vector is legitimate, I see a number of things that make it inherently infeasibly, and don’t think it really warrants being called a “FaceBot” (implying similar power to a botnet).

In order to create an application, one obviously needs to create a Facebook account, though that can be done anonymously.  The real issue is that in order to execute such an attack, one would need to make an application that is incredibly popular.  The attacker would need to devote a large number of resources to keeping such a popular app up, which would all need to be done anonymously (though would need to be paid for in one way or another).

Let’s say an attacker has gone through all of this to make a popular application: why doesn’t he/she just use those resources for a direct attack?  One possibly answer is that the Facebook DDoS would be hard to shut down, or better in some other way in executing the attack.  This is false because as soon as someone realizes that their traffic is coming from Facebook (whether by referrers, or FB trying to pull images for its cache, or some other mechanism), it can in most instances be stopped immediately, especially considering how most Facebook calls to other sites include the application’s API keys.  Even barring that, IP addresses and Facebook’s logging can be used to determine what application a user was in when they requested the victim’s site.

Additionally, DDoSs using this attack vector are relatively easy to mitigate.  If a hacker already has all of these resources dedicated to keeping an application up, why wouldn’t they just launch a TCP SYN flood or similar lower-level attack, much more potent DoSs, even if launched from a more limited IP range.

Let’s take a different route: suppose a hacker attacks one of Slide’s applications and somehow manages to break in and add an attack iframe.  This is a completely legitimate and anonymous way of attacking a site (though it begs the question of why the hacker didn’t just break into the target site in the first place, assuming both have similar levels of security).  While this is a legitimate issue, the same holds true for all websites.  Should someone hack into Yahoo! and figure out how to deploy a new home page (somewhere between almost-impossible and no-freaking-way on the difficulty scale), almost any site on the internet could easily be taken down.  I certainly hope top app developers take security as seriously as top website owners, but this is nothing special for Facebook.

On the topic of information theft, this is why Facebook requires you to explicitly permit an application to access your information.  The concept of an API implies this potential for theft…users are trusting applications to access their information and not keep it.  There is no way to prevent this for the same reason DRM doesn’t work: if people can view things they can store things.  While this is a legitimate concern, again it is nothing new, and not much can be done about it short of user education.

September 06, 2008 02:09 AM

As you may know John Slater and I have been creating a new Firefox logo style guide with the help of the Royal Order and a small team of community members who’ve volunteered as our informal panel of advisers.  We’ve made a lot of progress so far and hope to have the beta version of the site ready this month.  In the meantime both John and I will continue blogging about our progress at various stages to keep you apprised of all the details.  With that said, here is a quick behind the scenes look at one of the first challenges we worked on and the thought process going into it.

The Firefox logo is pretty straightforward, but over time we’ve actually accrued lots of alternate variations and lockup combinations - with the wordmark, product number, partner co-branding, etc.  When we took an inventory of all these we found around 32 different logos, which from a branding perspective was a pretty large amount of visual identities to have on tap.  So before we could work on the guide itself, we had to conduct an internal audit to clean and consolidate everything.  With careful consideration given to each one, we narrowed down the set to eight key logos that we felt had the strongest brand presence and represented the most common use cases.  Here they are:

Looking at all the existing logos, the first group that we decided to retire were the different partner lockups.  These can serve as a general template for co-branding, but each partnership is unique and requires specific treatment.  So going forward we felt its best to work directly with each partner and create new ones on a case by case basis.  Next, we chipped away ones that felt redundant or busy.  Including lockups that were communicating a little too much at once and confusing the information hierarchy.  For example this one which shows: the Logo (core product), Mozilla wordmark (parent company), Firefox wordmark (core product name), version number (product specific information), and of course the registered trademark symbol.

Our breakdown for the final eight goes something like this:

• Firefox logo is one of the primary visual identities and widely recognized by millions around the world. So this should be used as often as possible.

• Lockup with both wordmarks reinforces product name and Mozilla as the parent company.  This should be used for more general use such as press materials, T-shirts or posters.

• Lockup with a strong link to version number is best for communications specifically promoting Firefox 3, such as a download page or product info sites.

• Wordmark lockups without the logo are available for times when that is necessary.  Featuring the Firefox logo is always preferred, but if using the wordmark by itself, do so only when the Firefox logo is presented somewhere nearby.

• If you don’t have space for a horizontal logo, you can use one of the two vertical lockup options.

We put a lot of thought into these guidelines and feel pretty good about them,  but if you have any questions or comments please don’t hesitate to share it with us!

September 06, 2008 01:11 AM

While talking on IRC about how to make editable fields and the comment box closer so that you can easily comment and edit fields, especially the bug status, I suggested this mockup (ignore the fields you never heard about in the right column, those are custom fields). Is that something you would like to see officially implemented in Bugzilla? Or do you think it’s not better than what we have currently, i.e. the comment box just below the attachment table?

September 05, 2008 11:51 PM

September 05, 2008 09:59 PM

The second developer milestone of the next release of Firefox - code named Shiretoko Alpha 2 - is now available for download. Shiretoko is built on pre-release version of the Gecko 1.9.1 platform, which forms the core of rich internet applications such as Firefox. Please note that this release is intended for developers and testers only.

This Alpha of Shiretoko / Gecko 1.9.1 introduces several new features:

• Support for the HTML 5 <video> element
• Initial support for web worker threads
• You can now drag and drop tabs between browser windows
• New selector to create areas of Aero-style “glass” in XUL
• Support for CSS 2.1 properties: ::before and ::after, and white-space:pre-line
• Support for CSS 3 properties: -moz-border-image, word-wrap: break-word, text-shadow, box-shadow and column-rule
• Performance improvements and new preference values for color management profile support

Anyone interested in Shiretoko should read the release notes, as well as the “Firefox 3.1 For Developers” article on the Mozilla Developer Center before downloading. Please use the following links to download Shiretoko:

• Windows: Shiretoko Alpha 2 Setup.exe
• Mac OS X: Shiretoko Alpha 2.dmg
• Linux: shiretoko-alpha2.tar.bz2

We would appreciate hearing about any feedback you have, or any bugs you may find.

(Those interested in testing Mozilla’s new JavaScript engine “Tracemonkey” should note that it is not included in this development milestone. If you’re interested in that technology, please obtain a nightly build and follow these instructions)

September 05, 2008 08:04 PM

A quote from a Microsoft guy:

“I think that the next 18 months we’re going to see a 100 to 1,000 fold speed increase in JavaScript as Google and the guys at Mozilla are going to kick us all in the arse and make our JavaScript jittered,” Microsoft senior program manager Scott Hanselman told the audience, days after Google released its Chrome browser, which features faster JavaScript technology.

[...]

“It’s going to be hard to tell if it’s going to be Silverlight or JavaScript we’re going to use for our applications,” he said. “I think in the end JavaScript is going to be a bigger competitor to Silverlight than Flash is.”

Hell yes, we’re making the web kick ass.

September 05, 2008 07:52 PM

I've been working with the talented Sean Martell (of Kit and the Firefox 2 theme fame) on taking my Fennec interaction wireframes and creating a default theme for the browser. We're trying for something that nods back in the direction of Firefox on the desktop while still striking out in a direction that's appropriate for a small-screen finger-directed device.

He's posted some of the recent work to his blog, and he'll be posting more there as we go. This is a effort still very much in progress, so please jump in with your suggestions (generally or even about specific glyphs/icons). There's a Fennec UI discussion thread ripe for contribution.

This first set takes us through some basic Fennec operation.

1. Initial page load
When a page first loads, and you're still at the top, you see a Title Bar at the top, with an identity button and a reload button. You also have access to your bookmarks.

2. Movin' on down
As you pan down the page, the Title Bar scrolls off the top. The entire screen is dedicated to web content.

3. Take a step to the right
Panning to the right of a webpage causes the Control Strip to snap elastically into place — it provides most of the primary UI, including a starring (bookmarking) button, back and forward, and access to page actions (e.g. SMS this page to a contact) and browser tools (Preferences, Add-ons, and Downloads). There's more how these sections work in the wireframes, with pixel-designed screens on their way.

4. What about the other side?
Similarly, panning off the the left of the webpage gets you to your tab area, which also snaps into place. The bottom button, on the left, creates a new tab. The idea behind the button on the right is that you should be able to pull up, via Weave, a tab that you have/had open on your desktop.

More to come!

Update: My comments are broken, so please leave your thoughts in the Google group or on Sean's post. Sorry and thanks!

September 05, 2008 06:54 PM

I’ve been in interpreter-land lately, but I do help out a bit with static analysis projects when I get the chance. So I’d better post an update here on some interesting developments that haven’t been publicized yet.

First, Keith Schwartz (one of our interns) is making great progress on automatic const-correctification for Mozilla. The basic idea is to put const on as many declarations as possible without breaking the code or introducing casts. Keith has devised an algorithm based on type inference. Currently, he’s working on the Treehydra code to extract the type constraints from code. Because C++ is so complicated, there are a ton of details, and he’s had to master the insanity of GCC intermediate representations of pointers to member functions and calls through them. (If by chance, any readers know of a non-insane way to access them in GCC, let us know.)

Second, the Cairo folks were kind enough to give me an hour to talk about static analysis with the Hydras at their recent meetup. They already had 2 static analysis applications in mind. One was ensuring that internal-only return codes aren’t returned from the public API. The other was checking that integer and fixed-point values, both represented by C ints, aren’t mixed together. I think both of these can be formulated as type checking or inference problems.

I’m hoping we can extract a generic Treehydra type inference library from Keith’s code for the Cairo problems and others. One issue here is that Cairo is C, while Keith’s been using the C++ ASTs for his work. I don’t even know if Treehydra can read C ASTs at this point, but I think Treehydra’s design makes extending to C not too hard.

September 05, 2008 06:41 PM

September 05, 2008 06:30 PM

September 05, 2008 05:58 PM

As most of you know, Bugzilla 3.2rc1 is available for download since August 12 and bugzilla.mozilla.org upgraded to this version two weeks later, last Thursday. As I wrote in my last blog, b.m.o is not the first major installation to upgrade to 3.2rc1, so now seems a good time to get some feedback from people using this version of Bugzilla to know what’s their feeling with it, both about its UI and about its usability and new features. Mozilla folk reported a pretty large number of bugs, usability regressions, and complains, but as someone told me, they didn’t file bugs for things they like. So I thought this blog would be a better place to get your feedback, both positive and (highly?) negative, to get a better picture of what people think before releasing the final version of Bugzilla 3.2.

Note that this feedback can come from everybody using Bugzilla 3.2rc1 (or 3.1.4+), such as users of RedHat’s Bugzilla or OpenSSH’s Bugzilla, or even from smaller installations which already upgraded to this version. The wider the audience, the better.

September 05, 2008 05:13 PM

Recently there has been a lot of discussion on the topic of Firefox 3's warnings about SSL certificates which are invalid or not signed by a known authority ("self-signed"). Following on from johnath's earlier excellent blog post, our position on the subject is set out in "Firefox 3 and Self-Signed Certs".

This page explains why Firefox 3's SSL UI was designed the way it was, and why we think it's right.

September 05, 2008 04:44 PM

If you don’t read planet.mozilla.org or the Mozilla Web Tech blog, you’ve just missed out on a nice little article I wrote about some web developer features I implemented in Firefox before starting my A.T. thru-hike. If you’re into web development it might be interesting; I can assure you, however, that if you aren’t, it’ll be complete gobbledygook. In any case I’m sure at least some people in the latter category might be interested to see the sort of things I do beyond absurdly long backpacking trips, even if they won’t be able to understand them.

September 05, 2008 03:44 PM

Hello, web tech enthusiasts! I’m going to talk about a little feature I implemented back before taking a little hike, as part of fixes for Acid3: support for the DOM 3 Core Text.replaceWholeText() and Text.wholeText. Most likely you’re familiar with neither, as browsers only started implementing them in the last year or so, and I don’t recall hearing web developers clamoring for support for them, so here’s a brief summary.

Suppose you have the following simple paragraph within your webpage (with some whitespace added to aid formatting throughout the code samples here), whose DOM node is stored in the variable para:

<p>Thru-hiking is great!  <strong>No insipid election coverage!</strong>
  However, <a href="http://webarchive.nationalarchives.gov.uk/20100202110616/http://en.wikipedia.org/wiki/Absentee_ballot">casting a
  ballot</a> is tricky.</p>

You decide you don’t like the middle sentence, so you remove it:

para.removeChild(para.childNodes[1]);

Later, you decide to rephrase things to, “Thru-hiking is great, but casting a ballot is tricky.” while preserving the hyperlink. So you try this:

para.firstChild.data="http://webarchive.nationalarchives.gov.uk/20100202110616/http://planet.mozilla.org/Thru-hiking is great, but ";

All set, right? Wrong! What happened was you removed the strong element, but the removed sentence’s element separated two text nodes, one for the first sentence and one for the first word of the last. Instead, you now effectively have this:

<p>Thru-hiking is great, but However, <a
  href="http://webarchive.nationalarchives.gov.uk/20100202110616/http://en.wikipedia.org/wiki/Absentee_ballot">casting a
  ballot</a> is tricky.</p>

You’d really prefer to treat all those adjacent text nodes as a single one. That’s where wholeText comes in: if you have multiple adjacent text nodes (text and CDATA nodes for XML wonks), you can access the contents of all of them using wholeText. Let’s pretend you never made that last mistake. In that case, we have:

assert(para.firstChild.wholeText == "Thru-hiking is great!    However, ");

wholeText is just a property of text nodes that returns the string of data making up all the adjacent (i.e. not separated by an element boundary) text nodes together.

Now let’s return to our original problem. What we want is to be able to replace the whole text with new text. That’s where replaceWholeText comes in:

para.firstChild.replaceWholeText("Thru-hiking is great, but ");

We’re removing every adjacent text node (all the ones that constituted the whole text) but the one on which replaceWholeText is called, and we’re changing the remaining one to the new text. What we have now is this:

<p>Thru-hiking is great, but <a
  href="http://webarchive.nationalarchives.gov.uk/20100202110616/http://en.wikipedia.org/wiki/Absentee_ballot">casting a
  ballot</a> is tricky.</p>

With that, we’re all set.

Some uses of the whole-text functionality may be better served by using Node.textContent or the longstanding innerHTML; that’s fine and probably clearer in most circumstances. If you have to work with mixed content within an element as here, however, wholeText and replaceWholeText may be useful.

September 05, 2008 03:40 PM

So I decided to try out some new stuff over the weekend:

The first is using Amaya in place of Adobe Dreamweaver CS3, sometimes I think Dreamweaver is overkill for what I need and Nvu / KompoZer somehow didn’t cut it anymore. Yes, I kind of prefer WYSIWYG capability, so Amaya seemed to fit the bill, moreover it’s free and open source.

Second, I have lots of bandwidth to spare, and I just encountered the pain of trying to clone mozilla-central from scratch with a flaky and unreliable internet connection. No matter how long you try, it does not seem to finish, so I resorted to Benjamin Smedberg’s bundle file that saved me lots of agony.

mozilla-central:
Metalink to the mozilla-central bundle: (downloaded >400 times)
changeset 18525, updated as of 20080829-10:05:02 PDT. (74M)
SHA-1: 7d069e0a186c556ef1039ad03d0ebb5edb2b48d4

comm-central:
Metalink to the comm-central bundle: (downloaded >250 times)
changeset 227, updated as of 20080829-16:27:14 PDT. (7.6M)
SHA-1: ade283eca96c354d8b8eac63f2c17258e5bc5c57

Please try out the metalinks (generated here) as they will verify the download automatically with the SHA-1 hashes. The instructions below are adapted from his page.

Unbundle the above repositories using the following steps, substituting mozilla-central and comm-central as necessary:
1 - Create a new repository
$ hg init mozilla-central
2 - Unbundle it.
$ cd mozilla-central
$ hg unbundle /<path>/<to>/mozilla-central.bundle
3 - Tell Mercurial where you normally want to pull from by copying the following content into your mozilla-central/.hg/hgrc file:
[paths]
default = http://hg.mozilla.org/mozilla-central/
4 - Pull the latest changes and update your local repository.
$ hg pull -u
This way, the repositories should set up much faster if you have a flaky connection; you can always resume and verify your download if you are getting the bundle files.

Finally, I have also joined the current craze of writing Ubiquity commands, and I did up one (adapted from the MDC one by Eric Shepherd) that uses Google Search for NUS’s (my school) webpages, however, no matter how I try, I can’t seem to get it to work successfully. Basically, I set up everything properly, permit the javascript at the red permissions page, but nothing seems to occur after I type in the “nus” keyword.

Any ideas about this?

Edit: Upgrading to Ubiquity 0.1.1 fixed this issue for me. Note that you will have to unsubscribe and re-subscribe to each javascript subscription for it to work properly.

September 05, 2008 02:37 PM

There has been some changes to the SUMO team recently. Jason Barnabe, who maintains the Support Forum, unfortunately doesn’t have enough time to maintain a full-time job and administrate the Support Forum at the same time. He has made awesome contributions to the project over the year, and we’re incredibly thankful for that. Fortunately, he will remain an active SUMO contributor, so we certainly haven’t seen the last from him!

Also, our Live Chat maintainer Majken Connor (most of the SUMO contributors know her as “Lucy”) is moving on to explore other opportunities. We have all valued her contributions to the project and we wish her every success.

With that said, I’m very excited to announce the new team:

• Chris Ilias remains the “keeper of the Knowledge Base,” as he likes to call it. He is responsible for, among other things, reviewing article edits by the community, training and answering questions from contributors, improving our contributor documentation, gathering article feedback and statistics and ensuring that it is shared with the community.
• Matthew Middleton is the new Live Chat maintainer. Matthew started as a Live Chat volunteer back in January, and since then he’s become more and more active. He has actually been a Live Chat administrator in over a month now, but will now take an even more active role withing the SUMO community. He has impressed a lot of people at Mozilla recently with his incredible dedication, so I’m very happy to have him as part of the SUMO team.
• Cheng Wang is the new Support Forum maintainer, and will work on various things in the project, like administrating the forum, room monitoring Live Chat shifts, and collaborating with the rest of the team and even other parts of Mozilla like the QA team, to figure out our most commonly reported issues with Firefox. Cheng also started contributing back in January and has already made a huge difference by introducing new volunteers and helping the planning and organizing of events like the Support Firefox Days.

This picture was taken from the Mozilla Summit in Whistler, BC. From left to right: Nelson Ko, Jason Barnabe, Laura Thomson, Matthew Middleton, Majken Connor, me, Cheng Wang, Brian Krausz, and Chris Ilias.

Together we will work hard to make our users happy, grow our community, interact with other teams at Mozilla to share insights and information, and shape what we think will become the future definition of Open Source Support.

Stay tuned for part four of The vision for SUMO…

September 05, 2008 02:21 PM

September 05, 2008 02:15 PM

September 05, 2008 01:30 PM

Day 1 of Open Everything at Hollyhock has passed and I’m now up far too late blogging about it.

Numerous insights, but possibly the most interesting occured during the spectrogram exericse where we asked participants to physically locate themselves along an axis (in our case a piece of tape along the floor) in response to questions we asked them.

The most interesting was a two dimensional spectrogram where we first asked people if “The Organization I work for is open.” Then, after participants chose their spot along this first axis we asked them to migrate along a Y axis according to the question “I personally work in an open manner.” Below is a re-creation of how the participants distributed themselves around the room.

Obviously definitions of “open” and “how open” one is was up to each participant - but then this is the point of a spectrogram!

At first blush it simply seemed that many people were personally open (or trying to act in an open manner) in their jobs and that there was pretty equal distribution between who was in an open vs. closed organization.

However, the distribution of people in the quadrants was not random. Those in the bottom right quadrant (quadrant 2) tended to be people who were in more conservative institutions like universities, governments and traditional companies. These people were the IT professionals, consultants, organizers, etc… but more importantly, they were rabble-rousers within their respective organization, trying to initiate change. In short,  you had CHANGE MAKERS trying to shift their org into a more open space.

In the top right-hand quadrant (quadrant 3) were people in emerging open source projects and generally smaller organizations that were striving to be open. This was a group of people who’s organizations were become increasingly open. These ACTIVISTS believed in the open idea and were excited about where they - and their organizations - were.

Finally, in the top left hand quadrant (quadrant 4) were the VETERANS of the open movement. Here were people who worked in well established open source or open projects. Their challenge was they were experiencing the limits and issues of being and acting consistently in an open manner. As they push about against the most extreme limits of open they saw the necessity and value of not always been completely and totally open (for example, there are only so many thinking processes, conversations, and discussion, I can take the time to share).

So the big ah-ha was realizing the growth curve that people and organizations go through as they engage in, and become, more open. First you have change makers who agitate and work to enable organizations to adopt open methodologies. Then as the organization becomes more open people become activists, celebrating the open idea and pushing it into all areas of the organizations. Then those within the organizations begin to run into the operational and practical limits of open and, importantly, recognize the importance and role of “private” or “closed” as essential and so guard it. Critically, I also think that those in quadrant 2 or 3 are often measuring open differently then those in quadrant 4 - who because of their boards and/or stakeholders, hold themselves to a very high bar.

The best part about this is that it means there are individual and organzations lessons to be drawn as one migrates through these stages. It also means thatt those passionate about open, but in radically different quadrants (say 2 vs 4) may have very different priorities and/or concerns. This doesn’t mean that they aren’t both equally committed to a common ideal, just that they are looking at it from very different places.

September 05, 2008 12:31 PM

During the last day, I’ve been playing with a Firefox extension called “Feedly.” The home page for the extension is at feedly.com. As the extension describes itself:

Feedly is a new kind of RSS start page which weaves Google Reader, Digg and Delicious into a more fun, magazine-like user experience. The integration with Twitter, Yahoo Mail, Gmail, Friendfeed and Delicious makes sharing a breeze. You can get up to speed quickly by importing your existing Netvibes, Bloglines or MyYahoo accounts, your bookmarks or an OPML file.

What it does is act as a new way of viewing your feed content for those of us who read a lot of blogs (I scan at least 200, though some of those only update once a week). It uses Google Reader as its backend for accessing your feeds. For me, this is very convenient because I was already using Google Reader. This means that it reads my existing reader subscriptions, including folder organization, and presents views on it. When I mark items as read, save them for later, or share them, this is reflected on the Google Reader site. This makes it perfect for me and very easy for others to try if they are already playing with Google Reader.

Feedly offers various roll up views of top readers for blogs or other Google Reader information. It also allows you to use the “River of News” model for reading if you want to do so. One thing that I appreciated is that you can tweak a couple of different settings on how it presents feed contents to you. In the view below, I am using a short summary view with a small picture on a roll up page for one of my folders (personal-blogs). This gives me the first few sentences of each item and a picture. If I click on any item, it will expand in place to show me the full feed item. I can click on it again to collapse it or to choose options to save it, etc.

The only problem that I’ve run into so far is that it occasionally loses its synchronization with Google Reader so I see some of the same feeds or it offers me feed items that show as read in Reader if I go to it directly. This has only happened a few times but it is something that the software needs to work on. As a whole, I’ve found it to be a much friendlier way to use Google Reader and I plan to keep using it.

I’m not sure what the business model of the feedly.com site is for this but I expect that the search box at the top of each page may play a role. I haven’t noticed any ads or similar on pages yet. They do have a blog available and seem to be doing regular updates for the overall software.

This is for Firefox 3, only, of course. :-)

This work is licensed under a Creative Commons License.

September 05, 2008 05:40 AM

Some computations in JS take a long time, like this (incredibly poor!) implementation of the Fibonacci sequence:

function fibonacci(n) {
  if(n == 0)
    return 0;
  if(n == 1)
    return 1;
  return fibonacci(n - 1) + fibonacci(n - 2);
}

Any developer that puts this function on a web page and then asked for the 35th number in the sequence would succeed in locking up most browsers until the number was either calculated or the user got fed up and aborted the script.

Thankfully preliminary support for web workers has landed in Firefox 3.1 Alpha 2 so that expensive computations like this can be moved off to a background thread. The user interface will remain responsive while the JS engine churns and navigating away from the web page will even pause its execution.

Web workers are isolated from the main web page and can only communicate by passing string messages. Currently workers may only use timeouts, but there are lots more features that are just about ready:

• Creating workers from a url(http://webarchive.nationalarchives.gov.uk/20100202110616/http://planet.mozilla.org/rather than passing the text of the script)
• Dynamically importing additional scripts from the worker context
• Using XMLHttpRequest (with one caveat - access to the DOM is not allowed)
• Passing JSON-able objects as messages

The spec for web workers is still in (slight) flux and can be tracked here and here. Documentation and a simple example (of bad fibonacci) can be found here although please keep in mind that the current syntax is being changed to match the spec before Beta 1.

September 05, 2008 05:15 AM

I’m taking a break from garbage collection for a week or so: I got stuck, and there are lots of other things going on I wanted to help out on. Yesterday and today’s project was profiling some DOM testcases.

Two days ago, Jason recently landed a great patch to minimize the XPConnect overhead of DOM calls (fast-path DOM). Prior to this patch, many profiles of DOM scripting were dominated by XPConnect overhead (marshaling calls from JS to binary XPCOM). So I decided to re-do some of these profiles and see if there were any easy wins lurking, now that the noise was gone. I first ran the Dromaeo tests in a build from mozilla-central and compared the results to Safari on the same machine. Now, I’m taking some of the comparatively worst performers and using Shark to profile the tests.

I figured that getting shark to profile individual tests would require some major hacking. But it turns out that Dromaeo already has support for wrapping tests with calls to generate Shark profiles! All I needed to do was hack a little bit to generate a single profile at a time.

I started by profiling the following test: DOM Modification (Prototype): update(). mozilla-central was 8x slower than Safari on this test.

1. Start with a shark-enabled Firefox.
2. Download or clone Dromaeo from here.
3. Type `make web` to build a local copy of Dromaeo.
4. Start shark for programmatic control as documented here.
5. Point your browser at the test like so:

   file:///builds/dromaeo/web/index.html?dom-modify-prototype&shark=update&numTests=1

6. Shark should do a little dance and pop up a profile viewer. For a quick overview on using the Shark profile viewer, see Vlad’s blog.
7. By using the top-down view, I quickly discovered that over 70% of runtime was spent in a single function:

   

8. By double-clicking this function, I could see a heatmap of execution within the function: just two lines of code were responsible for most of the time!:
   .

9. This was more than enough evidence to file a bug.
10. After a bit of conversation with Brian Crower on IRC, I found that my initial hypothesis was wrong: The JS_ISSPACE
    macro is not really to blame. Every time it encountered a \s or \S in a regular expression character class, the code would loop over all 65,536 characters in the unicode basic plane and ask a series of lookup tables “is this character a space?” Because there are a small number of actual whitespace characters, I could replace this large loop with a small table of whitespace character ranges.

11. The patch made this particular test 77% faster, from 850ms to 195ms.

I’ve already filed a bug on another test and will be working through at least four more significant slowdowns. Doing this profiling has been a lot of fun, and a nice change of pace from the garbage collection slog. I really encourage anyone who has a mac to spend a little time with Shark and a performance issue: it actually makes visualizing and analyzing performance problems fun.

September 05, 2008 01:30 AM

This one has potential for alternative captions. If your feeling creative, leave a comment.

Hat Tip: I Can Has Cheezburger

September 04, 2008 11:48 PM

We will have a scheduled maintenance window tonight from 7pm to 11:00pm PDT. The following changes will take place:

• 7:00pm PDT (0200 UTC) addons.mozilla.org DNS change. As part of our CDN trial/test, we’ll be offloading addons.mozilla.org to CDNetworks and pushing a DNS change to make that active. See bug 450745 for details. No downtime is expected.

Please let me know if you have any reason why we should not proceed with this planned maintenance. As always, we aim to keep downtime to as little as possible, but unexpected complications can arise causing longer downtime periods than expected. All systems should be operational by the end of the maintenance window.

Feel free to comment directly if you see issues past the planned downtime.

September 04, 2008 09:16 PM

In the past, there has been some discussion about how SUMO interfaces with existing local community work. SUMO has been in place for one year now and we have shown many ways where local communities are working directly on support issues for end users. As SUMO grows, we need to be even more efficient as we work together.

SUMO and the local support communities

For many locales, I believe SUMO can really add value to their communities because we can provide things like a solid server infrastructure and an established wiki with a useful review system. But it really doesn’t stop there. SUMO is designed from the ground up to be a platform specialized on support. With the already existing SUMO community, we have shared access to a lot of interesting things, such as an overview of our most critical issues with Firefox, and a way to determine the quality of our content. We also have a pretty close collaboration with the rest of the Mozilla project, such as the amazing QA team. They can provide us with a lot of useful information, and we can do the same thing for them.

How does this relate to the support for your locale? For one thing, it gives you a better overview of what our users are most frequently asking, which helps determining what support content we should focus on. It also gives you the ability to determine the overall quality of your support by looking at things like which articles users find hard to understand. By working more closely with other Mozilla teams like QA and Firefox development, it might also help making your local community feel more involved with the rest of the Mozilla community.

On a more general note, I think we should all think about Mozilla as one united community. The important thing should be the fact that we come together to do all the great things that we do, not on what domain or server our accomplishments take place.

That said, for communities that still prefer to keep their support on their own infrastructure, how can we better promote that content on SUMO? Right now we’re linking to these sites on the “Other Firefox Support” menu item on the start page. Is that enough, or can we do other things to make it easier for our users to get help?

SUMO and Firefox

Another concern some local communities have with SUMO, or at least have had in the past, is its Firefox-centric focus. Readers of my personal blog might have already read my post The scope of SUMO, where I explained the reasons for starting with Firefox, and my thoughts on the project expanding in the future. Let me quote a part of it that I think summarizes it well:

In the future, when Firefox Support is doing really well, I could definitely see the scope being expanded to make the solution work for other Mozilla projects as well (and with the open source nature of the knowledge base and forums, it could even be used by other non-Mozilla projects, just like Bugzilla is used by almost every open-source project out there).

The work we’re doing on SUMO now is there to be done for other projects as well and will come in time. We’re not limiting ourselves to Firefox because we don’t care about the other projects, but because we need to focus on where our resources are needed the most first, and then broaden the scope.

Since that was written, the Thunderbird team has expressed interest in using the SUMO infrastructure to build a similar support site. What this means is that SUMO is not the equivalent of Firefox Support — SUMO really stands for Open Source Support.

How can we make the SUMO community stronger?

Let’s get back to the vision for SUMO. What can we do to strengthen and ignite our already amazing community? Well, an obvious answer would be to just ask the community members, and we’ve obviously done that a lot over the year. I’ve also talked to people at Mozilla closely involved with community building in other projects, to get their feedback. Based on that, we have some ideas to start with:

Understanding the bigger picture

I’ve already covered this in part two of this blog series, but this is definitely very related to building our community. To summarize:

• Work together – Closer collaboration with QA and developers to get a shared understanding of our users.
• Get everyone on the same page – Clear escalation paths for emerging issues that should be handled by other areas of the Mozilla project.

Karma

An online moderation/rating system –- also known as “karma” –- is important for a couple of reasons. First of all, it’s a way to encourage participation and allow contributors to really take pride in their work. How many users have you helped using Live Chat? How many have you helped in the Support Forum?

The other interesting thing a karma system would give us is better knowledge about which contributors are our most valuable. This is very useful information when e.g. surveying contributors about how we can improve the site — before making changes to the Knowledge Base article editor, which contributors have the most experience using it?

Showing more gratitude

What impact does a person writing a Knowledge Base article for SUMO make for fellow Firefox users around the world? The answer is, without a doubt, more than most people think. How can we make that clearer? Some things I’d love to see:

• Make the community more personal – Allow contributors to have a personalized profile with info such as full name, location, photo, and description. Make the people behind SUMO more than just a username.
• Show a photo of each contributor at the bottom of each Knowledge Base article under “Contributors to this article” — if they want to show their picture, that is. Make it more obvious to our readers that the content is written by people just like them!
• Add a plain and simple thank you note where appropriate, for example under “Contributors to this article” at the end of each Knowledge Base article.

A thank you note might seem trivial, but it really highlights some of the fundamental elements of a community: helpfulness, friendliness, and appreciation of each other. We’re not like any typical corporate support division. The motivator here isn’t money — it’s gratitude, appreciation, recognition, and a feeling of belonging to the community that motivate people to make a difference by helping people with Firefox.

SUMO is all about that.

September 04, 2008 09:15 PM

Google is now promoting Google Chrome on it’s homepage. Just a few days after release. Previously Firefox 2.0 was promoted on the homepage, a privilege normally reserved for Google products. The text link is a bit more subtle though. Maybe that’s because it’s beta and not 2.0.

It’s being shown to Firefox Safari and IE users. Interestingly it’s being shown to Mac users in addition to Windows users, despite no Mac support as of yet.

September 04, 2008 08:23 PM

I've been recently working on bug 449202: Get Thunderbird L10N builds working on comm-central. It's been mostly about using KaiRo's existing work for SeaMonkey and s/SeaMonkey/Thunderbird/g in the right places.

Ran into a few more problems, mostly my fault, and some having to do with the way the MoCo build network is setup.

Turns out it's also fairly complex to test this stuff, as the current setup relies on notifiers kicking on changes to the l10n repositories, so triggering a l10n build on purpose is a bit tricky. Instead, it was simpler to just wait for somebody to change something in one of the many l10n repositories and see what happens.

Well, I am happy to report that the first localized build of Thunderbird since the move to Mercurial has been produced and can be downloaded. It's only a single build, and for Windows, but more will follow as the normal churn in l10n repositories will trigger some more.

Then, the fun begins tonight, as the nightly builders should trigger a build of all of Thunderbird supported locales in one go. So, by tomorrow morning, we should have tons (43 locales per platform, to be precise) of new localized builds waiting for us, sweet!

Oh, and in case you had been wondering, the first successfull build is here. I think it's pretty cool that the first locale that successfully build turned out to be ga-IE, so that will explain the topic of this post. Hopefully, somebody from that locale will understand the title (and apologies if I butchered your language, feel free to correct me please)

September 04, 2008 08:13 PM

MobileHCI 2008 is on right now, and Tuesday was the workshop and tutorial day. They've posted the slides for all six introductory tutorials, along with quick abstracts. If you want to leap right in, they are, individually:

1. Text input for mobile devices by Scott MacKenzie
2. Mobile GUIs and Mobile Visualization by Patrick Baudisch
3. Understanding Mobile User Experience by Mirjana Spasojevic
4. Context-Aware Communication and Interaction by Albrecht Schmidt
5. Haptics, audio output and sensor input in mobile HCI by Stephen Brewster
6. Camera-based interaction and interaction with public displays by Michael Rohs

They're all worth flipping through if you're new to and interested in this space.

September 04, 2008 07:34 PM

I believe in tough love for my brain-children. It’s report card time. Let’s see how Ubiquity 0.1.1 holds up to my exacting standards.

For ease of learning, it should:

1. Accept input in something very close to the human language I’m already familiar with.

   B. It’s cool that I can put the modifiers in any order and use “this” and stuff, but the commands-are-hyphenated-requirement means that I often find myself typing awkward stuff like “add-to-calendar this”, which is not natural at all.

2. Give me clues about what commands are available.

   C. We’ve got the “command list” command and the context-menu to help people learn commands they don’t already know about, and you might notice a few commands in the suggestion list on your way to the one you want. But judging by the number of requests we get from the community for commands that already exist, I think this is still a major unsolved problem. And that’s just the commands you already have installed — finding out about a command that’s on the web somewhere that you might want is currently nearly impossible. We need a search engine for commands!

3. Give me clues about what I can type next.

   B. I think the suggestion list does a pretty good job of this — but it will do a lot better when there are more specific nounTypes and better sorting.

4. Give me clues about what the current command will do if executed.

   A. I think our preview feature pretty much nails this one.

5. Give me suggestions about other commands it thinks I might be looking for.

   F. Nothing is implemented for this yet, at all. I have some thoughts about how to implement synonyms, which I’ll be explaining in an upcoming post.

6. Help me understand what ranges of arguments to a command are valid, and what the arguments mean.

   C. The completions from nounTypes, combined with the preview pane, can give you a pretty good idea in some cases. But too many commands are using arbitrary-text arguments instead of more specific noun types. Mostly, we need to implement more noun types, and implement them better. Also, we don’t have a sensible system of defaults for command arguments yet, just a bunch of ad-hockery.

7. Propose commands appropriate to my working context or to the type of data I have selected.

   D. While this is technically implemented in the form of noun-first completions, the generic arbText commands push the specific stuff off of the bottom due to lack of sorting, so it’s an unusable feature.

For efficiency, it should:

1. Allow the user to start with the noun or to start with the verb.

   B. This works! But noun-first completion isn’t very useful right now, again, due to lack of sorting.

2. Let me autocomplete a partial word with a keystroke.

   D. Not implemented yet at all, though I can get some of the same effect by leaving my partially-typed word in place, hitting spacebar, and going on to type the arguments.

3. Recognize words even if they’re super-abbreviated.

   C. You can abbreviate the verb and most nouns, if you start at the beginning, and usually get the parser to recognize what you want in two or three letters. But you can’t abbreviate starting in the middle, or use a disjoint completion.

4. Remember what suggestions I’ve chosen in the past and pop them up next time I give the same input.

   F. Not implemented yet at all. I’ve got some ideas for how to do it.

5. Let me partially enter something, see the suggestions, choose one as mostly-right, and edit that one some more before executing it.

   F. Not implemented yet at all. However, I hope to implement the autocomplete-with-a-keystroke feature (see above) in such a way that it achieves this one too.

6. Guess, from my context and my selection, what I want, and fill most of it in for me, while letting me easily override it if it’s wrong.

   C. Noun-first completion and interpolation of the selection are a good start. But it will be a lot better once the suggestions are sorted, and once there are a few more magic words, and once interpolation of the selection can automatically go to any argument in the sentence. Ubiquity should be able to guess what I mean from context much more often than it currently does, as I described in this post.

For expressiveness, it should:

1. Handle commands with multiple arguments, including optional arguments, that can take various data types.

   A. We handle this pretty well! We just need arguments to be able to define defaults and whether they’re optional or not.

2. If I have data selected, let me use that selection as an input for any of the multiple arguments — or for none of them.

   B. Easy to do this with “this”. Need to make it better at automatically figuring out where the selection should go when there’s multiple arguments, though.

3. Let me chain commands together, with the output of one going to the input of the next, like Unix pipes.

   C. A very preliminary version of this is implemented as an undocumented feature. Needs a lot more work.

4. If my input could mean more than one thing, give me a sensible way to resolve the ambiguity.

   C. Suggestion list. It errs on the side of putting too many possible parsings in the suggestion list, though, so potentially useful completions are pushed out by trivia.

5. Let me compose a complex command out of small parts, in the flexible way that natural language does.

   D. You can’t do it yet, but I think we’re laying the foundation for it. The command chaining is a step in this direction, for instance. The potential is there to do a lot more of this.

6. Let me save a complex command that I’ve created and give it a simple name so I can re-use it in the future.

   F. Not yet implemented at all.

7. Give me an easy way to create my own commands — and to share them with others.

   A. I’ve been amazed by the quantity of third-party commands which have appeared and the speed with which they did so. We only launched last week and we already have a thriving third-party development community. What we need most now is a search engine for commands so that people can find what’s out there.

Needs Improvement

Given all that, here are the improvements which I think are most important to make to the parser next:

1. Sorting the suggestion list, both by the inherent quality of a match, and by what completions the user has chosen before for similar input.
2. Get rid of the hyphenated-command-names!
3. Add an autocomplete function, perhaps triggered with the tab key.
4. Allow abbreviations to match to the middle of words, not just the beginning. Also allow disjoint abbreviations, such as allowing “yts” to match “youtube-search”.
5. Implement synonyms for commands.

Additionally, we need to build that search-engine for commands, which is not technically a parser improvement but will make the Ubiquity as a whole much more usable.

Finally, there’s the internationalization issue. Making the parser easily localizable to various languages is a huge priority, but it deserves a post (or several) of its own, so I’m not going to get into it here.

Coming up next: Anarchy in the namespace, and what to do about it.

September 04, 2008 07:23 PM

We’ve previously talked about search engine marketing as one of the key marketing efforts here at Mozilla.  Those previous analyses have pointed to experiments we’ve performed that helped increase our efficiency by approximately 50% earlier this year (that’s pairing a reduction in total spend with an increase in total clicks).  While those are some great gains, we’re always considering additional ways to improve our efficiency, and ultimately the new user’s experience, through this marketing channel.

An example of a potentially untapped area for improvement is day/time parting, i.e., better targeting by day of week or hour of day.  Intuitively, it’s easy to imagine that a particular day (e.g., Fridays) or a particular hour (11pm PT) might see a lower price (cost per click) or differing interest among new users (click through rate).

Fortunately, this is a fairly easy hypothesis to test thanks to regression analysis.  With our AdWords account, we can grab hourly data and see what variables (e.g., particular hours of the day) cause the price/interest changes mentioned above.  Continuing our example, perhaps most advertisers run out of their daily ad budget by the end of day, causing late night hours to see a lessened competitive bidding environment, and consequently, a cheaper cost per click.  Regression analysis would be able to tell us exactly that - and tell us that perhaps we should be diverting more resources to such market inefficiencies.

Below is the regression equation and full regression output.  We used a recent data set from our primary campaign containing more than 4,300 hours, which equates to about six months worth of data.  Clearly our equation could be strengthened in different ways (more instances, more control variables).  For example, the results did improve when we substituted the day of week and month variables with a dayofweek*month interaction variable.  For any stats fans reading this, we’re open to other suggestions for improving our work (comments encouraged).

Cost per Click = α + β₁hour_of_day + β₂day_of_week + β₃month + ε

Note: hour of day results are relative to the midnight to 1am hour (pacific time), day of week results are relative to Fridays, and month results are relative to April.

So, how do we interpret these results?

• For hour of day, it looks like there’s little inefficiency to be found.
• However, the day of week findings are generally very robust.  Tuesdays, Wednesdays and Thursdays are relatively less expensive, and Saturdays and Sundays are relatively more expensive.
• At a macro level, these findings tend to point to a generally efficient market, meaning we likely won’t be changing our marketing decision making based on this information alone.

September 04, 2008 07:00 PM

When I started at Mozilla two years ago the biggest challenge was handling a release and pushing very close to 100Mbps.  Right around that point the firewalls would fall over.  We had one data center and essentially one provider and I could count the number of app servers on my two hands.

That was two years ago.  Today’s steady state is around 600Mbps and it’s not uncommon to push closer to 1.5Gbps during a release.  We have a growing global presence with four data centers and have enough redundancy built in that it wasn’t any problem to lose one provider this past weekend (well, it was a problem but it wasn’t user impacting).

The environment has grown from a bunch of switches strung together with a mess of cables to an orderly mess of cables and a switching infrastructure that’s allowed us to be more nimble and do more complicated things more easily, often without ever having to physically visit the data center(s). And there are something like 51 app servers.

The network has grown and I need help.  I’m looking for someone to join the team and continue to grow and support Mozilla’s network and systems infrastructure (job description is after the jump).

If you’re ready for the challenge and opportunity to serve a community of 200 million Firefox users, send an email to careers at mozilla dot com!

Network Engineer Job Description

As a member of our IT team, you will assume a pivotal role in creating the company’s core high-volume systems and network infrastructure and participate in key design decisions. You will be expected to come up to speed quickly to meet technical goals and challenges and share a leadership role in a hard-working and collaborative team. We have high expectations and are looking for a seasoned professional with experience in a wide range of areas. Your time will be split between pure networking and assisting with Mozilla’s growing Linux & ESX infrastructure.

The network environment consists of Cisco and HP switches and routers, Citrix Netscaler load balancers, and Cisco and Juniper firewalls.

Requirements:

You must be self-motivated, capable of managing your time well, and work efficiently without close supervision. You place a high value on secure, highly available, fault-tolerant systems. You are proactive in identifying and resolving technical challenges, enthusiastically troubleshoot problems when they occur, and thrive as a collaborative team player. Key duties include:

• Provide support in the operation of Mozilla’s growing global network infrastructure.
• Support Mozilla’s corporate network and remote offices.
• Monitor system stability and performance.
• Ensure 24×7 operations.
• Act as an externally-facing point of contact to facilitate handling of problem reports, and maintain relations with network peers and vendors.
• Act as an internally-facing point of contact to escalate technical issues, and communicate network status.

Job Skill Requirements:

• Bachelor’s degree in a technical discipline (or equivalent work in IT related field).
• 3+ years of experience with enterprise/IT level network infrastructure and/or ISP network operations center/tier 1-2 support.
• In-depth knowledge of TCP/IP fundamentals (including Layers 2-7 content switching).
• Creative problem solving abilities.
• Network routing protocol (OSPF/BGP) knowledge.
• Network certifications such as CCNP/JNCIA/JNCIP (or equivalent training/experience) preferred but not required.
• Strong knowledge of datacenter design and layout.
• Ability to document and update processes.
• Experience with standard network change management and configuration policies.
• Experience with Unix/Linux administration is required.
• Experience and flexibility regarding on-call responsibilities.
• Understanding of web application tiers (app, database, caching)
• Experience with scalability issues in both the network and application layers

Additional Skills Strongly Desired:

• Strong experience with OS deployment and automation
• Scripting/tools ability is a plus (Perl, Python or PHP)
• Familiarity with Cisco 6500, FWSM, Citrix Netscalers & Load Balancers
• Familiarity with iSCSI SANs

September 04, 2008 06:49 PM

Please note: everything in this article refers to the 0.1.1 release. The tip of the source tree is changing rapidly, so if you’re using Ubiquity from a source checkout, some of its behavior may have changed by the time you read this article.

Two months ago I wrote a post describing the properties of the ideal linguistic interface. Now that we’ve released Ubiquity 0.1.1, I want to look at how well the current state of the Ubiquity interface measures up to that ideal. Where does it provide the desired behavior and where does it still fall short? Where are there clear and obvious improvements that can be made, and where are we puzzled by design questions still murky and nebulous?

Is it easy to learn? How could it be easier? Is it efficient? How could it be more efficient? Is it expressive? How could it be more expressive?

Yes, it’s still in the public beta phase, so nobody should expect it to be perfect. All the more reason to correct UI design problems now, before they get baked-in and people start getting used to them.

The parser nitty-gritty

You can get the general idea of how the parser works by reading the new users’ tutorial and trying out Ubiquity for yourself.

However, there are some subtle-but-important parser behaviors that you might not notice at first glance. In order to understand some of the issues going on with the interface, we will have to dive into the implementation details of the parser. Ready? Here we go!

Click for larger version

This is the parser’s idea of an English sentence: A verb, optionally followed by arguments. The verb is always the first word. Each word after the verb is either part of the direct object or part of a modifier. The direct object is a noun, and each modifier is a preposition followed by a noun. Nouns can be multiple words (”hello everyone” is a single noun), but verbs and prepositions are only single words.

The parser expects every sentence to be like that, but it understands that sometimes parts of the sentence will be abbreviated or left out entirely. It’s not fazed by sentences missing expected modifiers, missing direct objects, or even missing the verb. It will also try to guess a partially-typed verb or noun (from as little as one character).

On execution, the direct object noun and modifier nouns, if any, are extracted from the parsed sentence, and passed as arguments to the execute method of the verb object.

Verb matching

The parser starts by splitting the input on spaces to get a list of words. It then looks at the first word to see if it matches any known verbs. It’s a “match” if a verb starts with the first word:

If the first word does match one or more verbs, then the parser attempts to do a “verb-first completion”:

If there’s no match, then the parser assumes the user has skipped the verb and gone straight for the arguments, so it attempts a “noun-first completion”:

Watch what happens if you type “calendar”:

The input “calendar” does not match to any verbs — even though we have commands called “add-to-calendar” and “check-calendar” — because those verb names don’t start with “calendar”.

Because it doesn’t match a verb, the input “calendar” triggers a noun-first completion. That’s why you get suggestions you probably didn’t expect, like “wikipedia calendar” and “yahoo-search calendar“. It’s because the parser is treating the word “calendar” as a noun, and looking for verbs that could accept that noun as an argument.

Verb-First Completions

So, the first word of the input matched a verb, did it? Great! Let’s do a verb-first completion. But wait a minute. Why do we only compare the first word? Can’t a verb ever be more than one word?

At the moment, no. We introduced the extremely lame restriction that verbs can only be one word, in order to make things easier for the parser. If you look at the command list, you’ll see that none of the command names have spaces in them. They have hyphens.

Click for a bigger image

Watch what happens if you input “add to calendar”:

The first word, “add”, is matched to the “add-to-calendar” verb. The “to calendar” part is parsed as arguments.

Single-word commands may be the standard in Bash, but that’s not natural-language! Typing “add-to-calendar this” is very awkward. I would greatly prefer to be able to type “add this to calendar”.

I look forward to improving the parser to the point where command names no longer need to be restricted, and we can drop the hyphens.

Aside from that major problem, the verb-first parsing is pretty flexible. See how it lets me provide the arguments in any order, for commands with multiple arguments:

The declaration of the email verb specifies that it takes a direct object, which can be arbitrary text, and one modifier, identified by the pronoun “to”, that must be a contact. This declaration informs the parser that it should look for the preposition “to”, and consider any words following “to” as candidates for the “to” argument. The word “aza” is given to the contact noun-type object, which looks through my contacts and produces two suggestions for completions; both of these possibilities end up in my suggestion list.

Notice what happens if I give email a “to” argument that’s not a match to anyone in my address book:

“your mom” is not a contact, and therefore “to your mom” is not a valid recipient. But the parser wants to use every word of the input. Since the “message” argument can accept anything, the parser treats “to your mom” as part of the message argument, and considers the “to” argument to still be blank.

Noun-First Completions

Sometimes it just makes more sense for the user to provide the noun first, instead of the verb. For instance, if the user selects some content on the page and then invokes Ubiquity, it makes sense to suggest commands that could act upon that selection.

It also makes sense that if, say, “check-calendar” is the only command that can take a date as an argument:

then if the user just types a date, we should be able to figure out that check-calendar must be the verb they want.

So, we implemented noun-first completion. If the first word of the input doesn’t mach any verbs, then it will be passed through all of the noun types that the parser knows about, to figure out what noun type it could be. For instance, an input of “tomorrow” gets a match from the Date noun type and the Arbitrary Text noun type. (Because “arbitrary text” matches everything, of course.)

Next, the parser builds up a list of every verb that can take any of these noun types as an argument. Since the “check-calendar” command takes a Date as an argument (as declared in the command definition), it will appear as one of the suggestions if the input is “tomorrow”.

Hey, what gives? Why isn’t it suggesting “check-calendar tomorrow”?

Well, actually it is generating that suggestion. But since “tomorrow” matches the Arbitrary Text noun type, it’s also generating suggestions based on every command that can run on Arbitrary Text, such as google and wikipedia. And those are the suggestions we see first.

This is not so good. We’d prefer to see the more specific suggestions first. Why don’t we?

The Suggestion List

The parser takes every possible valid completion and throws them all into the suggestion list. Only the top five suggestions are actually displayed; if we showed the entire suggestion list, it would often extend off the bottom of the browser window!

That’s because we’re taking every verb that matches the first word of the sentence — or, failing that, every verb that could use every noun type that matches the sentence — and producing multiple parsings based on it. Parsing is ambiguous (sometimes there are words that could either be part of a modifier or part of the direct object), and so every possible alternate parsing goes into the suggestion list.

This is the approach we use wherever and whenever we find ambiguity in the user input: produce every possible interpretation, and throw them all into the suggestion list. As another example, when the input contains the magic word “this”, we suggest both the literal sentence and the sentence with the seletion substituted for “this”:

To expand “this” or not to expand “this” is an independent binary choice, so it doesn’t just add one extra item to the suggestion list — it doubles the length of the suggestion list. Each time we introduce more flexibility into the parser, the suggestion list grows geometrically!

The suggestion list is not currently being sorted.

Let me say that again: The suggestion list is not currently being sorted. At all!

I assumed throughout development that the only way the throw-everything-into-the-suggestion-list approach would possibly result in a usable interface was if the suggestion list should be sorted by quality, so the best suggestions always appear at the top.

To my great surprise, I discovered once I implemented the suggestion list that Ubiquity seems to work fairly OK without any sorting. Not great, not humane, but usable. We had other higher priorities so we delayed sorting until after the 0.1.1 release. Now that 0.1.1 is out, the sorting algorithm is the main thing I’m working on.

But for now, remember — when you type something into Ubiquity and see a list of five suggestions, those aren’t the best five, they’re just the first five that the parser can come up with. That’s why you’ll see google and wikipedia and so on as the suggestions for any noun that you select. And that’s why noun-first completion isn’t very useful as it currently stands.

Coming up next…

I’m going to grade Ubiquity 0.1.1 on all the criteria I introduced in part 1. Then I’m going to tackle the current lack of any naming standards, and what it means in a world of wide-open decentralized command development.

September 04, 2008 06:28 PM

So, you might have heard that Google released a web browser.

One of the features of this web browser is its JavaScript engine, called v8, which is designed for performance.

Designing for performance is something that Google does often. Now, designing for performance usually leads to complexity. So, being a major supporter of software simplicity, I’m opposed, in a theoretical sense, to designing for performance.

However, Google is in an interesting situation. Essentially, we live in the Bronze Age of computing (or perhaps the Silicon Age, as I suspect future historians may call this period of history). Our computers are primitive, compared to what we are likely to have 50 to 100 (or 1000!) years from now. That may seem hard to believe, but it’s always hard to imagine the far future. Google is operating on a level far exceeding our current hardware technology, really, and so their design methods unfortunately can’t live in a theoretical fairy-land where hardware is always “good enough.” (However, I personally like to live in that land, when possible, because hardware will improve as time goes on–an important fact to understand if you’re going to have a long-lived software project).

What is it about our computers that makes them so primitive? Well, usually I don’t go about predicting the future in this blog, or even talking about too many specifics, because I want to keep things generally applicable (and also because the future is hard to predict, particularly the far future). But I will talk about some of my thoughts here on this, and you can agree with them or not, as you please.

Our Current Computers

First, you have to understand that to me, anything that could be running this web browser right now, that could be showing me my desktop, and that I could be typing into right now–I’d consider that a computer. It actually doesn’t matter what it’s doing underneath, or how it works. A good, offhand definition then of a computer would be:

Any piece of matter which can carry out symbolic instructions and compare data in assistance of a human goal.

Currently computers do this using math, which they do with transistors, digitally. The word “digital” comes from “digit”, a word meaning, basically, “fingers or toes.” For most people, your fingers and toes are separate, individual items. They don’t blend into each other. “Digitally” means, basically, “done with separate, individual numbers.” You know, like 1, 2, 3, 4–not 1.1, 1.2, 1.3. People (normally) have 1 or 2 fingers, not 1.5 fingers.

Said another way, current computers change from one fixed state to another, very fast. They follow instructions that change their state. I don’t really care if we say that the state is “transistor one is on, transistor two is off, transistor three is on…” or “Bob has a cat, Mary has a dog, Jim has a cat…” it’s all a description of a state. What we care about ultimately is the total current state. If there are 1,000,000 possible states (and there are far, far, far more in a current computer), then we can say that “we are at state 10,456″ and that’s all we really need to know.

The problem with current computers is Moore’s Law. We don’t need computers that are twice as fast. We need computers that are about a million times faster than the ones we have. We need computers so fast that software engineers never have to worry about performance ever again, and can just design their code to be the sanest, most maintainable thing possible. With that kind of performance, we could design almost any software imaginable.

The problem is that with Moore’s Law, we’re not going to get computers 1000 times faster for about 20 years. We’re going to get to 1,000,000 times faster in about 40 years. And there’s a chance that the laws of physics will stop us dead in our tracks before that point, anyhow.

Future Computers

So, let’s stick with the idea of a machine that changes states for the near future, because I can’t think of any other clever way to make a computer that would follow my definition from above. There are three problems, then:

1. How many states can we represent?
2. How many physical resources does it require to represent all those states (including space, power, etc.)?
3. How quickly can we change between states?

And then “How many states can we represent at once?” might also be a good question–we’re seeing this come up more and more with dual-core and quad-core processors (and other technologies before that, but I don’t want to assume that everybody reading my blog is an expert in hardware architecture, and I don’t want to explain those technologies).

So the ideal answers are:

1. We can represent an infinite number of states.
2. It requires no physical resources to represent them.
3. We can change between them without time.

And then also “We can represent an infinite number of different states at once.”

Currently we theoretically could represent an infinite number of states, we’d just have to add more transistors to our chip. So really, the question becomes, “How many states can we represent with how many physical resources?” Currently we can fit two states into 32 nanometers. (That’s one transistor.)

My suspicion is that the future is not in fitting two states into a continually smaller space, but in fitting a near-infinite number of states into a slightly larger space. Electricity and other force waves can be “on” or “off”, but they also have lots of other properties, many of which are sufficient to represent an infinity (or near-infinity). Frequency of any wave represents an infinity, for example–you can have a 1 Hz wave, a 1.1 Hz wave, a 1.15 Hz wave, a 1.151 Hz wave, etc. So, that basically answers Question 1 ideally–you can have an infinite number of states, you just have to have some device which is sufficiently small, in which a wave can have its properties modified and measured by electronics, optics, or some other such technology.

You’ll notice that we’ve also conveniently answered our bonus question, because we can represent quite a few different states at once, once each individual component of our system can represent an infinity all by itself.

If we want to look a bit further into the future, our second question can be answered by the fact that waves take up essentially no space (only the medium that they vibrate takes up space). Our understanding of physics is not (as far as I know) currently good enough to create structures out of pure force just yet, but such structures would come quite close to taking up “no physical resources.”

And beyond that (how we get the state changes to happen without time), I have no idea. That question may be unanswerable, and may only be resolvable by changing computers to being something other than mathematical devices. (That is, not be involved with states at all, but some other method of following instructions and comparing data.) But the better our components become, the closer we can get to “no time.”

The Roundup

So there’s my thoughts for the day on the future of computing. Sometimes designing software for performance is a necessary evil (but really only in the case where it’s an extreme issue, like with Google’s products, or the great new need for speed in JavaScript nowadays, or in other low-level places), but I hope that future changes in the fundamental architecture of computers will obsolete that necessity.

-Max

Comments: 11

September 04, 2008 06:00 PM

Previously, we’ve examined the new development practices that the Songbird team adopted to plan and track a release. Everyone on the team was very eager to put them to the test. Unfortunately, at the time, we were still in the middle of the 0.3 release cycle and new work could only be started once that release was completed. During the 0.3 release, everything was still treated as a bug, but in fact, many bugs were stories and tasks in disguise. We decided to apply some of the newly defined tracking principle to help us guide and finish the cycle, so we could start fresh with our next release as soon as possible.

Cuánto es?

The first step was to add cost to everything. We introduced a new cost field in Bugzilla and put a cost value on everything according to our new scale of 1, 2 and 3 points. With costing in place, we were in a position to compute how much points the team was able to complete in a typical work week. That total, normalized per work day became our team velocity.

Below is a chart representing our velocity over many — one week — iterations during the 0.3 release (code name Bowie). The blue line is the number of points the engineering team completed, averaged per work day. The red line tracks the cost of new things being introduced, normalized per work day. The green line tracks the net velocity.

It quickly became apparent that as the team took things off the pile, new work was being identified and added. We had to keep track and take this into account. We named this intake to globally represent new functionality, regressions and newly discovered bugs.

The net velocity gave us an indication on how well we were doing overall. When it gets in negative territory, we are losing ground.

You can see below 3 events that had clear impact on intake, namely scope creep (some features were not well defined upfront), and bug intake due to public feedback from a blessed build and a release candidate.

Also noticeable is a week when the team was not as productive as usual. With that information in hand, we were able to have open conversations about the state of progress and try to determine the cause for it. Sometimes, a low velocity is simply because work gets accumulated in a week and does not get checked in until the next. We call this carry over. Other time, there are some inevitable distractions such as a move, interviews, equipment failure, etc. In other cases, the team is just having a bad week.

With this in place, we were able to understand the rate at which the team was completing work. We created a burn down chart that tracked the total points of known work left. Using the team velocity, we could forecast an expected release date with a simple best fit projection. When the line crosses the X-axis, you are done and can ship.

If you compare the two charts, you can see how much influence intake had on the release. This became a key component to take into account in our planning. By budgeting points towards intake, it allowed us to reserve some engineering capacity to take change into account upfront and have a more realistic schedule.

Where does intake come from?

By formally tracking our intake, we were able to better characterize the nature of change. Most of our intake comes from change introduced when features start to materialize in the product and can be tested. This is a desirable effect of adopting an Agile practice. Other contributors are defects being reported by existing users, which is a benefit of early releases. Less desirable intake come from regressions or new tasks that resulted from bad assumptions or misunderstandings. Those can usually be mitigated by increasing unit tests coverage and more upfront detailed planning.

Full Agile cycle

Let’s take a look at another release cycle. Dokken was our second release in which we used the new process from inception. The charts below represents velocity and burn down respectively. Note that the scale on the velocity has increased. There is more dynamic range. Because the release started from day 0, we noticed a ramp up in the velocity. We learnt not to be necessarly alarmed by this. In a new release cycle, the team needs some time to “prime the pump” of development. As the release progressed and we got better visibility of the team progress, we decided that we should defer feature work that was identified as nice-to-have. This is another thing we did during planning. We prioritized work in must have for the release, hope to have for the release and nice to have - mainly cosmetic changes, low risk bugs - buckets. This gave us a pre-negotiated way to easily shift features as the release progressed.

By actively tracking and managing the intake, we were able to steer the release and deliver within weeks of the projected date. Not great, but better than our previous releases. Dokken was a particular difficult release as we undertook a lot of device support work, which can lead to nasty device compatibility problems.

Embracing change

The next release, named Eno presented some interresting characteristics. The intake was relatively high thru the release but the team was also maintaining a higher velocity. This is a good example of the team achieving a good level of agility. Change is being introduced throughout the release and the team is well prepared to tackle it. Also notice that the spike in intake due to feedback from release candidate has a corresponding level of increase in team velocity. This is due to the shortening of feedback loop. With proper ownership, the developers are able to respond in real time to issues being discovered.

Notice how the burn down trend is converging almost linearly. This means that the team is achieving a sustainable pace, leading to more predictable ship date.

Achieving high velocity

Our latest release, Fugazi is another example of a successful cycle. This was the shortest release cycle the team ever undertook, with only 4 weeks of planned development work and 3 weeks of QA. In order to maintain our original release date, we had to defer some lower priority work in iteration 3. Despite the shorter release period, the team actually completed more points per iteration than any other release. We maintained an unprecedented high velocity, which in turn allowed for a high level on intake to be absorbed, so all the planned must have featured could be kept in the release and still hit our original target date.

DIY tools

In the last part of the series, we’ll cover the tools we created to make the tracking easier and how they are being used on a daily basis to help us steer the release. Stay tuned.

September 04, 2008 05:40 PM

We’re always on the lookout for new/better ways of visualizing data.  Blake recently pointed me to an awesome tool called Many Eyes, which is a relatively new effort by IBM’s Collaborative User Experience.  As they explain it, “Many Eyes is a bet on the power of human visual intelligence to find patterns. Our goal is to ‘democratize’ visualization and to enable a new social kind of data analysis.”

It looks like their community members have already created more than 18,000 visualizations, with several even relating to Mozilla in some way.  For example, the visualization below takes an internet population data set from internetworldstats.com and displays it via a treemap (it was created by the user seadub ealier this week).  I encourage you to click on the image below to see for yourself just how interactive and valuable this tool can be.  From just a fraction of a second glance, it’s easy to see that Asia represents the largest internet population by a fairly large margin and that China and the U.S. are the largest countries.

September 04, 2008 05:07 PM

I promise, my blog is not going to turn into a “desktop wallpaper collection”, but this one is too cool not to show it to you:

“Ceci n’est pas le fond d’écran officiel de Firefox / This Is Not The Official Firefox Background Picture”

By the way, the photographer Denis-Carl Robidoux publishes a picture per day, all of which in different sizes to fit your screen, and for free, too.

September 04, 2008 03:33 PM

As discussed during the Summit last week, Mozilla Labs is now reaching out and calling for participation in exploring possible future directions for the Web. In particular, we're hoping to engage the wider design community who have not traditionally been involved in open source projects or design.

The first iteration of the concept series will hopefully provide additional ways for designers and other non-programmers to participate and become part of the Mozilla community.

Our hope is that new voices, ideas and concepts will challenge our collective thinking, facilitate discussion and provide inspiration.

Learn more about the concept series at: http://labs.mozilla.com/2008/08/introducing-the-concept-series-call-for-participation/

September 04, 2008 03:17 PM

I have just uploaded a new version of my Webchunks extension (implemention of IE8 Webslices for Firefox). It's available from my own site for the time being, and will be available from addons in the coming days. Changelog:

• now correctly deals with multiple entry-title elements,
• v0.14 was incorrectly disabling JavaScript
• clicking on a webslice entry while the webslices were refreshed on window's load was horking the webslice popup
• cleanup

September 04, 2008 01:39 PM

In case you hadn’t heard Mozilla are running a developer day in a week or so’s time in Toronto. The first day is aimed at giving a good overview of the Mozilla platform and what technologies it offers. The second day will be a more hands on workshop where you can try your hand at extensions, applications and testing with friendly experienced people around to lend a hand when you hit problems. It isn’t far off now so get yourself signed up if you’re coming.

I’m in the midst of trying to put together what I’ll be talking about so if you have anything you particularly want to hear then make a suggestion.

September 04, 2008 01:30 PM

Last weekend I decided to play around with the new Ubiquity extension for Firefox, building a command.

The command is called 'vote' and it gives you the ability to bulk vote on links and comments on Digg, Reddit, and Hacker News.

I've created a short screencast that shows it in use:

Ubiquity Vote Command

• Install Command
• View Source (Github) - Note: While functional, the code is highly unoptimized at this point.

Here are the commands available on the sites that it supports:

Digg

• vote up - Works on stories and comments that haven't been voted on.
• vote down - Works on comments that haven't been voted down.
• vote fave - Works on stories that you've already voted up.
• vote bury - Works on all stories.

Reddit

• vote up - Works on stories and comments that aren't already voted up.
• vote down - Works on stories and comments that aren't already voted down.
• vote none - Resets the vote of stories and comments that have already been voted on.
• vote hide - Hides stories from view.

Hacker News

• vote up - Works on stories and comments that aren't already voted up.

Each of the commands have a number of filtering aspects that can be used:

• vote up WORD - Performs the vote on all stories or comments that match WORD (comments will also match the name of the comment author). For example: vote up google
• vote up REGEXP - Performs the vote on all stories or comments that match the REGEXP regular expression. For example: vote up hadron|youtube
• vote up WORD not OTHER - Performs the vote on all stories or comments that match WORD and does not match the word OTHER. For example: vote up google not chrome

Ubiquity is a lot of fun to develop for. There's a real-time command editor (run the command 'command-editor' to bring it up) which makes development quite fast. It also includes native jQuery support (which is a huge plus for me).

In a lot of ways I see Ubiquity as being a solid replacement for Greasemonkey and bookmarklets. It's far simpler and will make their execution much more flexible. I'll be curious to see what people end up doing with it, in the upcoming months.

September 04, 2008 09:51 AM

Now that we’ve taken a macro view of a few uninstall survey trends, we can dig into some of the details. The following two charts summarize the response to the second multiple choice question: “Why did you uninstall Firefox? (select all that apply).”

The initial results are encouraging. Fewer users uninstalled due to printing, security, usability, missing features, and web page rendering. Furthermore, more users were planning to return to Firefox! Perhaps the biggest surprise is the 2.6 percent increase in users uninstalling due to performance. We do not know whether this increase is due to (perceived) slower performance, to more crashes, to installation difficulties, or to a change in expectations.

While the response trends are generally positive, the survey itself has a number of areas for improvement. I have identified three areas where the uninstall survey falls short:

• The question wording is unclear (performance, security, etc.)
• The responses are clustered around 12% and don’t provide a clear area of focus
• The responses are broken down by neither geography nor localization

Perhaps most troubling is the low response rate, depicted in the chart below.

Of 113,000 visitors to the uninstall survey in March, fewer than 8,000 left a multiple choice response. And, of those respondents, only 826 left a comment. I expect that the low response rate is due to the fact that that the survey is not localized. Nearly 90 percent of visitors to the uninstall survey live in non-English speaking countries.

In the next post I will suggest new questions for the uninstall survey and propose survey tool solutions that may help Mozilla address these areas of concern. Please leave your thoughts and suggestions for uninstall survey improvements.

September 04, 2008 09:24 AM

Due to the power of extensibility in Mozilla Firefox, it's relatively easy for Firefox to clone most of Google Chrome features. Actually most of the cool feature of Google Chrome is already in Mozilla Firefox.

So check out the article on how to:
Enable Chrome's Best Features in Firefox

Also check out the speed test between Firefox, Chrome and Internet Explorer:
Beta Browser Speed Tests: Which Is Fastest?

There's also a comparison between Google Chrome and Internet Explorer 8
Lab test: Google Chrome vs. Internet Explorer 8

September 04, 2008 08:50 AM

Since I spent a relevant portion of my past two days answering email messages similar to the following, I decided to post a catch-all answer here.

Hi Giorgio,

I just read Google’s introduction to its Chrome browser.
I was so impressed with its security features that I may even switch from Firefox to Chrome. (I didn’t think that was even possible when I first heard of Chrome.)
Would you consider adapting your NoScript add-on to it?
I tried out Chrome and loved it, but the absence of NoScript was immediately apparent!

Seth

Hi Seth,

I’ve been playing with Chrome since it’s been available, and I cannot say I’m impressed with its security.
I do like its speed, but Fx 3.1 builds with TraceMonkey enabled are already faster.
I really love its taskmanager: opening a random MySpace page and watching CPU and RAM consumption skyrocketing blamed precisely on the Flash plugin (70MB Flash, 28MB the page itself versus 11MB for an empty tab) is kind of cool, even if it comes with the cost of redundant resource allocation (if it was Firefox, crowds would be screaming “memory hog”).
On the other hand, there’s nothing apparently novel in its security approach, and it doesn’t address any in-browser security problem, such as XSS or CSRF, at all.

The worst part, though, is that Chrome is not nearly as extensible as Firefox: cynical people may suspect this is to prevent something like AdBlock Plus or NoScript itself to be ported, biting advertisement bottom lines.
This is such a bummer that Google had to issue a late announcement about an extension API, but if it’s gonna be like Opera’s widgets (as I strongly suspect) it won’t help.

BTW, one of Chrome’s most hyped features, stability due to the claim you might crash one tab but not the whole browser, fully justifies the “beta” tag:


Cheers
–
Giorgio

September 04, 2008 07:23 AM

One of the problems we had with the Firefox Support Knowledge Base in the past was that locale leaders and approvers had no way of knowing when a new translation was created. As a result, new translations stayed in the unpublished staging area with no-one knowing that a review was needed.

In a recent support.mozilla.com update, a new feature was added enabling you to receive notification whenever a new translation is created in your language. You can even monitor more than one language if you want. Here is a page with instructions on how to enable it. Happy translating!

September 04, 2008 04:44 AM

I am currently in Harpers Ferry, WV with 5.8 miles remaining in this thoroughly idiotic accomplishment. I do not have the energy to find a good resource that describes what this is, beyond what you can probably guess it is. (I might continue an extra three miles to the first shelter in VA, which would also net fifty miles for the day, but that decision will definitely wait until after the state line.) If someone can find such a resource, I’ll update this post with it when I can. Four State Challenge will work about as well as anything for describing what the challenge is. After grabbing some food (wrapped deli sandwich or similar) to eat for dinner when I stop for the night, I’m heading back out to finish the day; hopefully I’ll be able to eat the food and get a bear bag or something going before collapsing into sleep from sheer exhaustion.

Tomorrow’s hike will be a shorter-than-average day.

Update:

• There’s apparently some funky trail-winding near the border such that it’s only 1.9 miles to one crossing of the Virginia border, so in reality that was all the distance I actually needed to cover. The Thru-Hiker’s Companion book doesn’t really make this clear, and 5.8 is to the last of the “Virginia sections”.
• I ended up completing the full 5.8 plus the remaining 3 to that first shelter, for 51 total for the day.
• Even if you’re a thru-hiker, you can never let your ego grow too huge, or else it’ll be deflated when you read the register at that first shelter and discover another crazy southbounder started from even further into Pennsylvania and thus hiked a 60-mile day. I never had any illusions of extreme hiking prowess, but if I had, the southbounder “Rock Layer” would have trashed them completely.

September 04, 2008 04:43 AM

Today I fixed a few pages in the XUL Reference that were using unsupported MediaWiki commands to do conditional text. While Deki supports conditional text, it doesn’t yet offer the ability to look at the name of the page including another, so we’ll have to do it the old-fashioned way for a while. I also fixed an amusing typo in the XULRef template. Oops.

I’ve also checked into SVN some more changes to the skin for the site, this time changing the default fonts from serif to sans-serif, in response to popular demand. The print version should still be using sans-serif fonts, for easier reading on paper. I’ve filed a ticket with IT to get this revision activated on the server; hopefully that will happen in the next day or two.

I know a lot of folks are still frustrated with the new site, but I continue to hope that as people get used to the changes they’ll grow to like it. And, of course, now that MindTouch has finished the Killen Woods release of Deki, I’ll be able to hound them incessently — without guilt — to make more changes to make our lives better. Bwwwahahahaha!!

Ahem.

As I was saying, we’ve got plenty to do still. Most of the good feedback, including folks pointing out serious problems, didn’t come until after the launch, which is why there are so many rough edges at the moment. We’ll get them ironed out. It’s my mission in life to do so. And that’s not even hyperbole; it’s my job to make MDC rock, and that’s what we’ll do. Even if it takes a little longer than everyone would like.

September 04, 2008 04:04 AM

I’ve made a bunch of good progress on mashTape this week, finishing up the RSS & video providers today, and adding a bunch of new RSS providers. The number of sources mashTape now has by default includes: * Last.fm (artist bio, photo, and tags) * Freebase (discography, band members) * MusicBrainz (related links) * Flickr (photos) * Google News (rss) * Google Blog Search (rss) * Yahoo News (rss) * MTV News (rss) * Hype Machine (rss) * Digg (rss) * YouTube (music video) * Yahoo Music (music video)

Here are a bunch of screenies of how the interface is currently looking. Obviously nothing is finalised, but all the data hookups are more or less functional. There are no preferences hooked up yet, but I hope to work on that soon.

September 04, 2008 03:14 AM

September 04, 2008 03:00 AM

I’ve been trying out Chrome on my Vista machine at home, and I read a few hundred comments on Chrome last night on Digg. Here are my first thoughts, just as a browser user and an engineer.

Responsiveness. The most noticable things right away are that the UI is minimalistic and very responsive. The screen responds promptly to clicks, and UI elements appear, disappear, and move around very quickly. Responsiveness makes any tool (or toy) more enjoyable to use. So I like that a lot.

AFAIK, Chrome’s UI is straight C++, so that plus the minimalism should make it very fast. Firefox, of course, has a bigger UI coded in XUL/JS, which gives FF more features and excellent extensibility. I would never want to see FF give up extensibility, but I would sure like a snappier FF. I have no idea what that would take; speeding up JS should help, perhaps some sort of XUL tuning or overhaul is needed as well.

Process Isolation for Tabs. Less technically known as process-per-tab. This looks great. Diggers love the idea as well. Personally, I want it so that one bad web page or Flash app doesn’t hang my whole browser. That seems to be what the Digg users like best about Chrome too. There’s also reliability-one really bad page won’t crash the whole browser, although FF crashes are rare for me anyway and the state restore option makes crashing not too painful. And security, so that a maliciously bad page can’t overwrite memory on anything else. I haven’t used Chrome enough yet to see these situations come into play, so I don’t know it will work in practice, but for now I’ll assume they got it right. There’s still the question of whether the Windows schedulers give enough isolation to maintain performance, too.

Anyway, I want it.

There is a tradeoff: Chome seems to use more memory, at least with several pages open. (I tend to run with 20-80 pages open at a time.) Chrome actually tracks the memory nicely. Type about:memory into the location bar, and you get a summary of memory for all your open browsers, including FF if it’s running. Very cool.

<technical-gobbledygook>Memory consumption on modern OSs is complex enough so that it’s difficult even to define clearly. Chrome’s “task manager” (press Shift+Esc) is reporting the private working set size. This is the same number Vista Task Manager displays by default. The private working set size is the amount of physical RAM allocated for the exclusive use of a process. (The full working set includes physical RAM accessible to to the process but shared with others. The term “working set” comes from the OS’s allocation strategy, which tries to allocate just enough physical RAM to cover the virtual memory the process touches frequently, which is called the “working set”.) about:memory also shows the virtual memory allocation (I think Windows calls it the “commit size”), which is the “true” (ignoring a few complexities, I’m sure) amount of memory used by the process. I think that for an active app, the total allocation is more relevant, because either it will be in memory, or frequently paged in and out, bogging everything down. For paused background stuff, the working set can be more important, but if it’s paged out, the total size will determine how long it takes to come back up when you ask for it. On my system, Chrome was using more memory by both metrics, but I didn’t use Chrome heavily enough to see any serious paging or thrashing, so I don’t know how it plays out in practice yet.</technical-gobbledygook>

The extra memory consumption might make Chrome less suitable for mobile devices. So process per tab should be an option for FF, but not required. Also because not everyone will want it on their non-mobile devices.

Ideally, I think process, thread, and DOM tree (i.e., tab) should be orthogonal concepts in the browser platform. The DOM tree is a unit of visual display and window control. The process is a memory protection domain. The thread is a unit of sequential execution. The user and the browser would control the policy of how many processes and threads are created and how they are assigned to tabs.

As an example of what you could do with this, you might have a default policy where each tab is a process, with each separate script or plugin being a separate thread inside that process. Thus, the tab is protected from other tabs, and its dynamic elements can run concurrently. But now say that one of those scripts loops. The other scripts might still be running OK, but with less CPU because of the looping script. If you want, you could shut down just this tab, and leave the other tabs unchanged. It’s dangerous to kill just one thread, because it can leave the memory inside the process inconsistent. But at worst, only this tab would crash. If it did, you could reload the page with a policy giving each dynamic element its own process. At this point, you could kill just one element on the page while leaving the rest running.

A more exotic example would be to assign two processes to one tab. This seems weird, but it would be possible if the 3 concepts were orthogonal. One use would be to allow two other elements (tabs or scripts) to interact closely with a element. Interprocess communication is expensive, but as long as the other two elements use the shared element one at time, we can just map the shared item into both processes, so they can access it relatively quickly.

Of course, that’s a lot of work. I hear there’s also some problem where the MacOS Core Graphics APIs make it harder to implement multiple processes for one browser window than it is on Windows.

Awesome Bar and Places. Chrome has some version of FF’s Awesome Bar and Places. Which is a good thing-at this point I would find it painful to use a browser that didn’t. I think the location bar has some Googlyness in it too, like Google Suggest or something. I started typing the names of some of my favorite blogs, and it got the popular ones after a few letters even though I’d never visited them before in Chome. That was pretty nice, but I imagine after you’ve used the browser for a while, you have visited your favorites anyway, so it won’t matter too much. But I use and love FF’s Awesome Bar so much, I think I would like having search/suggest even more integrated with it. It’s a small thing, but it could make the browser just that little bit more responsive and direct.

So far I’ve found the bookmarks interface kind of weird. It bothers me that I either have no bookmarks menu at all, or else an ugly toolbar strip across the top of the browser. But I think it’s good they’re trying something new-I think Places is great but will continue to improve. Personally, I use the Awesome Bar for all navigation to a single site. I only use the bookmarks menu to open a group in tabs (e.g., morning blog reading), or to bring up a group in the Ctrl+B view and click on various items in turn (e.g., Youtube playlist). So there’s probably some mystical third design (not to mention 17 existing FF extensions) that would be better for me.

I’m really not excited by tabs on top of the window, or the thumbnail view of open pages. That stuff doesn’t work when you have 26 tabs open.

V8, blah blah blah. V8 is the other hot topic on Digg. I’ve heard Zimbra runs really well on Chrome, but I personally haven’t done anything with it as a user where I really noticed a difference. TraceMonkey vs. V8 has been covered elsewhere, so I’m not going to bother with that. Plus all these VMs are pretty early, so I’m not terribly excited about day-by-day benchmarks.

What I am immediately interested in is what techniques the V8 team actually used, how it relates to my inline threading project, and what ideas I might be able to steal from it. But I’ll have to read the code and report on that another day.

September 04, 2008 02:11 AM

Oh internets, you hysterical zeitgeist, please simmer down. Google Chrome is not the end of Firefox. Another open-source browser is not going to bring down Mozilla’s ten years of development and evolution overnight. Here’s a quick 10 reasons not to panic:

10. Chrome is going to have problems releasing on Mac and Linux. You have to imagine it broke Google’s heart not to release for Mac and Linux when they released for Windows. The only conceivable reason they didn’t release for all must be huge, ugly dev problems that will take a lot of time and work to tackle. For instance, I’m guessing they can’t do multiple process rendering to a single window on Mac yet. There’s no supported way to do this as far as I know. And that’s only the beginning of the challenges involved with multiple processes (more here).

9. Chrome wants to be like Firefox. Many of Chrome’s main features - such as its “omnibar,” private user mode with icon, one-click bookmarks, and drop-down notifications are lifted directly from Firefox’s features and planned features. In places they used Mozilla’s code directly. I think this says that Chrome would like to be more like Firefox than its statements imply.

8. Chrome’s got security issues to work out. One biggie is its vulnerability to carpet-bombing attacks. Another is malicious links through undefined handlers.

7. Navigating your tabs and windows is impossible in Chrome. In Firefox, not only can you install one of a countless number of extensions for organizing, sorting, coloring, grouping, fading, and poking your tabs , but also cool new features are being added that allow you to visually navigate your content. How do you find your tab in Chrome? You don’t… tabs are the same color, have no favicon or visual differentiation, and there’s not even a way to see the names of tabs when you have too many in a window.

6. What we’re hearing about Chrome is mostly hype. Chrome’s an interesting new project from Google, so of course the media is chroming at the mouth (pun credit) to tell you all about it, but this is how the media makes money. A plethora of coverage does not prove Chrome is the best browser, it proves it is the newest. We won’t really know what people think of Chrome until the smoke clears and people use it in their daily lives.

5. Chrome is an unfinished product that still lacks polish. While most Google products are in “beta,” this one has a ton of kinks to work out. Google’s documented some of the bugs here, and new ones are being reported here. Sure, Firefox has plenty of issues itself, but Mozilla’s been documenting and fixing them for a decade. Chrome isn’t even fully compliant with CSS yet. For more on why Chrome lacks polish, see Peter Svensson’s article

4. Mozilla has a dedicated fan base. I’d argue more dedicated than any other browser’s users. Have you ever met a passionate user of Internet Explorer? Chrome has plenty of people excited, but it’s unlikely to gain the same kind of loyalty that Firefox enjoys from its users worldwide.

3. Competition will only make Firefox better. Competing with Internet Explorer can at times be a bit too easy, because the product is so bad and so different from Firefox. But Chrome offers new challenges in the areas Firefox cares about, such as open standards and open source. Finally, a worthy competitor for Mozilla. I also predict that Mozilla will be more willing to make substantial improvements faster now that Chrome’s in play. And, unlike Google, Firefox is Mozilla’s flagship project and has the undivided attention of many more developers. Mozilla’s focus is fixed on the browser, but Google’s main attention is on search revenue.

2. Chrome can’t match Mozilla’s extensions, tools, and plug-ins. Mozilla has an ever-growing community of developers who build excellent tools for customizing your web experience. For nearly anything you want to change about your experience in Firefox, an add-on is available for free. If it’s not there, you can write and distribute your own add-on. Many of these add-ons have their own communities and companies - they’re established and depend on Firefox to reach their users. Chrome is starting out with nothing comparable in place and thus a user experience that isn’t customizable.

1. You can’t beat Mozilla’s community. What makes Firefox awesome is its volunteer army - the thousands of developers and supporters throughout the world that contribute to Firefox’s evolution. Forget even the Mozilla employees - the community is the heart and soul of the project. This is something Google can’t develop easily, even with all their employees and resources.

So what we’re looking at is not the end of Firefox, but another exciting step towards open innovation on the web. For a more on Mozilla’s exciting new challenges, see Mitchell Baker’s and John Lilly’s comments.

September 04, 2008 02:07 AM

September 04, 2008 01:19 AM

/**
 * namespace «name» */

if(typeof(«name») == 'undefined') {
    var «name» = {};
}

(function() {
    «»
}).apply(«name»)

if (test1) {
....if (test2) {
[8SPTAB]do_something();
....}
}

sub foo {
....<|>
}

sub foo {
....if (test1) {
[8SPTAB]if (test2) {
[8SPTAB]do_something();
[8SPTAB]}
....}
}

September 04, 2008 12:50 AM

It’s been well-documented that this year’s Mozilla Summit was a fairly eventful week, what with a highway-blocking rock slide, bear sightings and a half-day power outage on top of the talks, sessions, ping pong games, dinners, etc.

At the suggestion of Deb Richardson, we decided to immortalize the various dramas by turning them into a laptop sticker. Tim Hogan from the Royal Order was there to experience it all firsthand and was kind enough to translate the excitement into the artwork below (based, of course, on the original design by Nobox).

So, if you did indeed survive the Summit you should be getting one of these in the mail sometime in the next few weeks:

September 04, 2008 12:24 AM

September 04, 2008 12:21 AM

Google has launched a new open source browser, Chrome. The new browser boasts a minimalistic UI, a new Javascript engine dubbed V8, and sandboxed tabs to prevent one tab from crashing the browser. Chrome uses components from Apple's webkit and Mozilla Firefox.

Gigaom has published an article including comments from Mozilla CEO John Lily that while Microsoft, Apple and Google have other businesses and agenda, Mozilla's singular agenda is to make the web better.

PCMag has published an article commenting on blog posts from John Lily and Mozilla Foundation Chairperson Mitchell Baker. In his blog post, John Lily addresses how the introduction of Chrome affects Mozilla and its relationship with Google. Mitchell Baker commented on Mozilla's open development process and the need to continue building great products in a competitive environment.

CNet News Webware has articles commenting on Chrome's Javascript performance and Chrome's fine print, specifically auto update.

Last week, Google and Mozilla extended their search partnership until 2011.

News of Google Chrome leaked early when the comic book explaining Chrome's features was published before Chrome was formally announced.

Talkback

September 03, 2008 10:33 PM

Certain other cool open source projects are doing cool static analysis work. In this case, here is an analysis of one of my favourite operating systems projects, DragonFly BSD.

I’m blown away by the clean UI. The error filter and the interleaving of static analysis results in the source code are drool-inducing. This is powered by the clang checker. Clang’s checker doesn’t yet do C++, doesn’t do application-specific checks and has a lot of false positives, but it’s an exciting preview of things to come.

Oh and I hope that DXR will have similar analysis awesomeness. In the future, I hope to see static analysis become almost as common as unit-testing.

September 03, 2008 10:09 PM

September 03, 2008 09:30 PM

Interface design is hard work, so it’s really nice when someone else has done much of the heavy lifting for you and left their labor open to cherry picking.  :)  The Mozilla platform has been getting a number of upgrades in large part due to the work of the Firefox team and thankfully I have no shame in stealing the work of our compatriots.  Here’s how you can do it too.

What to Steal

I started in the Preferences area because we (TB & FF) share many of the same mechanisms used to change preferences.  Also it’s difficult to get preferences done right so it’s nice to be able to take all the hard work someone else did there and make it our own.

In Bug 451620 — “Remove the Advanced Preference for Connection timeout” we are cleaning up a preference mostly used for debugging and therefore doesn’t really belong in the main interface.  While working on the patch I took a look at FIrefox’s preferences to see what they were doing in that area and noticed they have the exact same preference, but it looked cleaner and nicer.  So I took it.

In Bug 452711 — “Use firefox default font chooser for display” I wanted to improve a users ability to change their font preferences.  Currently Thunderbird requires a user to change fonts with the daunting font dialog now available from the Advanced button.  In making this patch I went straight over to the Firefox font preferences and ported it over to our code.  Again, I have no shame about taking this either.

How You Can Steal Too!

Stealing code for preferences is easy, so easy, that I (not a programmer) can do this in a fairly short amount of time.  It only takes a reasonable knowledge of HTML/XML (XUL can help) and Javascript.

There are lots of this kind of preferences work to be done and it’s a great way for a new person who wants to submit a patch into the codebase to get a sense of the process.

Here’s a step by step on how I’ve been borrowing their code such that anyone should be able to do it.

Step 1 - Source Code

Get the source code from steps in the Comm-Central source code wiki page.  This step takes a little while as it downloads all the necessary components to build Thunderbird.

Step 2 - Initial Build

Build Thunderbird initially, you should only need to build it entirely once.  Follow the steps to create your .mozconfig or you could just try mine, which gives you a debug build.

export MOZCONFIG=~/tbsrc/comm-central/mozilla/browser/config/mozconfig
. $topsrcdir/mozilla/browser/config/mozconfig
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/tbird-debug
mk_add_options MOZ_CO_PROJECT=mail,calendar
ac_add_options --enable-application=mail
ac_add_options --disable-optimize
ac_add_options --enable-debug

Then run the build command as they describe.  Now go get some coffee or something.

Step 3 - Start Stealing

Time to start stealing!  Move into the Mail Preferences code and open up one of the files (check out Prime Places to Steal for ideas).

(from src)
cd mail/components/preferences/

Then at the same time go into the Firefox preferences and open up the preferences file that has the component pieces you’re looking to steal.

(from src)
cd mozilla/browser/components/preferences/

Step 4 - Building Your Theft

Now as you viciously swap pieces from the Firefox preferences over to Thunderbird preferences you don’t need to rebuild the entire Thunderbird source code, just the preferences component you’re changing.

Move into the preferences component on the build directory.  (this assumes you have a tbird-debug directory, which you’d get if you used my .mozconfig file)  There should only be a Makefile in this directory so type “make” and it will build up the preferences component.

(from src)
cd tbird-debug/mail/components/preferences
make

If you were to change any of the strings (preferences DTD files) used in the DTD that the XUL file references then you’ll need to rebuild the locales jar, which is just as easy.

(from src)
cd tbird-debug/mail/locales
make

Step 5 - Testing Your Theft

Now you’re ready to run your new version of Thunderbird!  You’ll likely want to create a different profile than your normal profile.

(from src)
./tbird-debug/mozilla/dist/bin/thunderbird -P test

Common Gotchas I Encountered

Here are some common errors I hit that were annoying to work through.

Parse Error: If you add code with references to DTD entities ( often labels like “&colors.label” ) that don’t exist you’ll get a parse error that’s pretty difficult to understand.  Check that your DTD has the correct entity ( <ENTITY colors.label “Colors:”> ) and that you’ve built the jar from the locales directory.

Adding New Files: If you’ve added new XUL and DTD files you’ll need to add references to those files in the “.mn” file.  Don’t ask me why!  I just work here.  See the preferences jar.mn and the locales jar.mn files, the format is pretty obvious.

Prime Places to Steal

Bug 451599 — “Add preferences UI for disk cache size and clearing the cache“.  To implement this bug you really just need to grab the Firefox Preference code from line 221 to line 233 and copy it just after line 216 of the Thunderbird Preferences code.  You’ll need to poke around at the related Javascript code for hooking it up.   And don’t forget to copy the strings from Firefox advanced.dtd file into the Thunderbird advanced.dtd file.  See, no shame at all!

Another one is the continuation of Bug 452711 — “Use firefox default font chooser for display” where you can copy over the color chooser.  First apply the patch provided in the bug. Copy the Firefox colors.xul file over to the Thunderbird preferences directory and the colors.dtd over to the Thunderbird preferences locale directory. Don’t forget to update both jar.mn files (and build the jars) as mentioned in the Gotchas section.

Then have a look at the code for the Firefox Content Preference and grab the row from line 195 to line 201, the button which launches the color chooser dialog.  You’ll also need to grab the content.js configureColors function and add it to the display.js code.  Don’t forget to change “chrome://browser/…” to “chrome://messenger/…”.

Making and Submitting Your Patch

Once you’ve made your changes and tested them out you’ll want to open a new bug, and upload your patch to that bug.  Use the hg diff command to make your patch, I generally do something like this.

hg diff --git > ~/Desktop/stealing-ff-preferences.patch

Make sure the new bug is against Thunderbird Preferences, use this link to get the product/component entries correct, and attach your patch along with that new bug.

Don’t forget to CC me on that bug!  Use my email: clarkbw at gnome . org

Legitimate Sharing

Stealing isn’t right.  It’s not that we want to copy all this code, which can create known issues of code sharing.  However I defend this especially for something like the preferences UI which goes under a considerable amount of churn each release; making it difficult to place those elements in a lower layer like toolkit for optimum sharing.

Once we’ve played catch up for a bit I hope that Thunderbird can start sharing code back as we create new improvements on the current systems.

September 03, 2008 09:11 PM

September 03, 2008 08:52 PM

It has been a few weeks since I last talked about archiving content on www.mozilla.org and I wanted to post an update. We’ve removed a first batch of pages from the site and are still working to make sure that we’re redirecting and migrating any content from this batch that is still in use today. This process is ongoing and we apologize for any inconvenience this has caused.

We’ve heard that the archiving process has caught some people by surprise, so I want to post information about the content we’re looking at for the next round of archiving. For the following links we’re looking at migrating the developer documentation to MDC and archiving any other content that is out of date and no longer being maintained.

• Migrate http://www.mozilla.org/directory
• Migrate http://www.mozilla.org/docs
• Migrate http://www.mozilla.org/editor
• Migrate http://www.mozilla.org/profilemanager
• Migrate http://www.mozilla.org/rdf
• Migrate http://www.mozilla.org/rhino
• Migrate http://www.mozilla.org/scriptable
• Migrate http://www.mozilla.org/unix

If you have comments, questions or suggestions about what to do with any of this content, please feel free to comment in the relevant bugs. If you are the owner of any of this content, we will be getting in touch with you before making any changes.

September 03, 2008 08:45 PM

It's that time of year kids; back to school. Being a student myself, that meant leaving my cushy home in San Francisco for my apartment in Toronto. It is good to be back home, even though I miss San Francisco.

Now that I am back at Seneca, I am very excited to get started with my third last semester. The thing I have most to be excited about is enrollment in Dave Humphrey's Open Source development course. My project for this course will be creating a BitTorrent add-on for Songbird. I can't wait to get started!

As part of my first class, Dave requested that I read The Mozilla Manifesto, read The Cathedral and The Bazaar, watch Revolution OS, and listen to a podcast interview of Mike Shaver talking about The Mozilla Manifesto. Having completed the above, my beliefs in the benefits of Open Source and what it is has only been solidified. Completing this task also emphasized some of the things I learned through my involvement with the Mozilla Project over the last 18 months and my involvement with Songbird over the last year.

I do not want to get into a long essay, so I will summarize what I mean with an example from Songbird.

One of the key principles cited in The Cathedral and The Bazaar is to release early and often.

...If the overriding objective was for users to see as few bugs as possible, why then would you only release once every six months (or less often), and work like a dog on debugging between releases...

The typical release cycle for Songbird is between 6 to 8 weeks. While this exposes users to more bugs than would exist in a software that is released every six months; it provides user feedback far sooner in the development process. Anyone who has worked in software development knows that user feedback is always worth more than its weight in gold.

The downside of this is that you are exposing users to potentially faulty software (more likely it is). This, in turn, can open yourself up to hordes of complaining users and damage the image of your software or the company. However, as I have seen with Songbird, most users realize the software they are installing has potential flaws and accept this as a hazard that goes with the territory.

Sure you will run into users who still complain, and some can be completely irate; I have found, at least with the Songbird community, for every upset user, there are 10 more users that uninstall the software but are willing to check back in a future release. Some users are even willing to bare with the issues until an update is provided. These users, for a most part, believe in the potential of the software.

For the most part I believe that Songbird use the software because they want to; iTunes users use it because they need to or have accepted the marketing.

This is just one of the things I like more about Open Source than closed source. Like I stated earlier, I always believed this principle; the Mozilla Manifesto and The Cathedral and The Bazaar only solidified this belief. If you have not read these documents and are interested in what Open Source is about, I recommend reading both and watching Revolution OS.

Anyway,

Thanks for tuning in...stay tuned for Episode 2.

September 03, 2008 08:42 PM

With the release of the Chrome browser, Google presented two ways to measure its global impact with the localization of its Web browser: languages available and presence in number of countries. (Take a look at the opening line of this article.)

Gerv and I have both blogged a bit about how Mozilla tries to measure the impact that its community has by localizing Firefox for Web users across the globe.   Specifically, we look at both the number of localizations and the percent of the world’s Internet population covered by Firefox with our translations.  We don’t really measure by country boundaries.

But, to see how we rated against this Chrome metric, Pascal ran an analysis to see how many countries a user could find Firefox.  He started by looking at the total number of countries listed by the U.N. Then, he looked at the Wikipedia entry for each country to find the official language spoken.  By that count, Firefox is in 161 countries.

If we were to add that to our list of metrics, for the upcoming release of Firefox 3.0.2, we can provide the following about Firefox:

• Firefox is present in 161 countries
• Firefox is localized in 57 languages officially shipped across three platforms
• Firefox has 93.1%* of the world’s Internet population covered

I guess my first question that comes up when I think about coverage in terms of countries:  what happens to languages that do not map to geopolitical boundaries?  Guys like Erdal from our Kurdish localization probably have some thoughts on that.  What about India?  Do the people in Andhra Pradesh think that India can be represented as a country if Telugu is not a localized option for their browser?

Admittedly, I think our metrics are a better measurement (though slightly incomplete…see below) of the impact of a localization effort.  It would be nice to open this conversation to the guys at IE, Safari, Chrome, Opera, Flock, etc.  We have a lot of open discussions about security, performance, and standards.  How are these other browsers looking at localization metrics?   Did the Chrome team use the same methodology we did above to get the number of countries?  What are the other metrics that help illustrate impact?  Perhaps it’s wishful thinking, but I’d like to learn more from the other localization teams.

*  I’ve mentioned before how we get this percentage and that our model is a bit incomplete, but here is how we think about our metrics:

Our goal is to count the number of people in the world speaking different languages who have access to the Internet, irrespective of country boundary, and then see where Firefox localizations provide coverage.  Our premise is that some countries (like the U.S.) have people whose native language may not be the official language of that country.  Therefore, we’ve set up a matrix where across the top we list most languages spoken in the world.  We have a column that lists all countries.  Then, we do as much research as possible to find out how many people in each country speak another language “at home”.  The assumption is that people who speak a different language at home would also like to browse the Web in those languages.  In the case of the U.S., one might expect to see its population speaking English, Spanish, Arabic, Chinese, and so on.  The biggest challenge is getting accurate data of who speaks what languages in each country.

September 03, 2008 08:36 PM

It’s September, the time of year when students head back to school and professors plot.  Almost all of my existing Mozilla students have graduated and started working, and I’m left all alone, *sniff*.  Well, not quite.  We’ve just welcomed 35 new students into our open source courses.  I’ll be taking them deep into the mystical land of Mozilla, while my colleague, Fardad, will be doing the same with OpenOffice.org.  Meanwhile, Chris Tyler, who taught the Mozilla courses with me last year, is leading a new grad program (LUX) on Linux in partnership with Red Hat and Fedora.  It’s awesome to have so much open source going on here!

I was looking for a way to throw these new students directly into the fray and give a sense of what it’s like to develop Mozilla, how to use the web as a collaborative tool, etc.  Not being one who likes to do the same thing twice, I suddenly realized that a lab on Ubiquity hacking would be perfect.  In this first course, we have students work toward a 0.3 release (which they take to 1.0 in a subsequent course), and working with such a holy-crap-this-is-awesome prototype like Ubiquity is perfect.  A huge thanks to the Labs and Ubiquity crew, who have done a really good job documenting and explaining their stuff.  I was joking with jorendorff today that I’m a big believer in the “hole in the wall” method of teaching (see video):

Hopefully doing a “hole in the browser” will achieve my aim of getting the students started on this open source journey.  I’m thrilled to have something like Ubiquity to use for this.

Also, with new students comes the opportunity to get people working on things.  I’m already talking with a bunch of folks about project ideas, stale (or super fresh!) bugs, and other things you’d like to get some love over the next 8 months.  If you have ideas, please do let me know.  Even smaller things are in scope, as students need so-called “Contrib” marks for doing things on other projects, which are not their main focus.

As in previous years, watch out for new people wandering around Mozilla trying to find their way.  Mozilla is one of the most welcoming projects I’ve ever seen, and I’m grateful for it.  I look forward to getting these students contributing in the weeks to come.

September 03, 2008 07:29 PM

Firefox  3 has been nominated for 3 awards at the 2008 .Net Awards

The 3 categories are:

- ‘Open source application of the year’

- ‘Viral campaign of the year’ (Download day)

- ‘Standards champion’

Cast your vote for Firefox and others here: http://www.thenetawards.com/

September 03, 2008 07:14 PM

I use profile for Thunderbird in several different manners. First, there is my Mozilla stuff; I would like to collect all my Mozilla-related messages, etc. into one place. Second, there is my Usenet persona, which is different. Then there is school, and finally other personal relations. So I should (ideally) have four identities each representing how I want to appear. When I write a message, I should be able to select which identity I want to express.

Now how does it work right now? I have 9 identities--each new account I create (4 email, 5 news) creates its own identity. Deleting them more or less requires me to go into my prefs.js (or about:config) and pruning them. Oops. The compose window right now is probably confusing (I have four email addresses selectable but 9 entries in a drop down saying "From"... hmm...), but then again, compose needs its own basket of love. Finally, simultaneously posting to a newsgroup and emailing is... hairy, to say the least. The normal case is at best confusing or redundant while the abnormal case is infuriating.

There's a third piece that needs consideration with identities&emdashaccount type extensibility. RSS accounts in the future may want to allow you to comment on posts&emdashor possibly even write new posts yourself. Similarly, other account types will probably want to have some way to let users write in a generic, HTML manner, what composer is good at. The difference here is in means of transmission.

From a user standpoint, all of this can be done in easy steps. Account creation wouldn't create new identities for each account type, but would allow you to specify an old one or have you create your own. For extensible account types, all that has to be done is to mix in your own compose stuff, present the necessary UI (if any), and the necessary backend hooks. Posting to, e.g., both news and email is as simple as adding a registered newsgroup header (i.e., Newsgroup) and adding a registered email header (i.e., To, CC, or BCC) in the compose window.

September 03, 2008 06:07 PM

I read a lot of web feeds. Hundreds of feeds bring me thousands of stories on all manner of topics every day — Mozilla stuff, food and cooking, photography, gaming, news, technology, literature, writing, politics, business, innovation, design, etc. Feeds are how I get almost all of my news, whether it be local, national, or international. It’s how I view my friends’ blogs and my Flickr contacts’ photo streams. Feeds keep me up to date on most forums and newsgroups I follow, and they’re the first place I turn when I want to waste some time catching up on my entertainment news or to see what’s up at the renovation/interior design blogs I read. Feeds are, by and large, how I access the vast majority of the Web content I consume.

Until a few days ago I have been using the Vienna feed reader for Mac OS X. It’s a pretty decent workhorse of a reader with a standard email-client-like user interface, the ability to group feeds into folders and subfolders (and sub-subfolders), and all that. It has always frustrated me, however, that my feedreader — through which I consume the majority of my Web content — wasn’t part of Firefox. In fact, I could go so far as to say that Vienna was on close to equal footing to Firefox as my core tool for accessing the Web. This has always struck me as somewhat ridiculous, so I’ve played with all sorts of tools for reading feeds via Firefox, whether they be add-ons or web-applications or what have you. None have ever been compelling enough to switch me away from Vienna until now.

I’ve discovered Feedly, you see, an incredibly slick Firefox 3 add-on that’s been in development for quite some time.

While I’ve only been using Feedly for just over a week now, it has already completely streamlined how I manage, view, and deal with my feeds. Brilliantly, Feedly leverages the existing Google Reader web application as its back end, and throws in added functionality, other service integration points, and a significantly improved UI for good measure. It installs as quickly and easily as any Firefox add-on, displays your feeds in their own tab, and essentially integrates your entire feed reading experience right into your Firefox. Feedly is almost exactly the sort of tool I was hoping to find, and while it does still have a few bugs and rough edges, it’s by far the best feed reader I’ve used to date.

Check it out: Feedly at Mozilla Add-ons.

September 03, 2008 06:04 PM

So, V8. Well-hyped. It’s got a cool logo. And many claims are being made about its performance. But it is not the only kid on the block. As we blogged about a couple of weeks ago, Mozilla has been investing over the last couple of months in a super-fast JS engine as well.

In terms of claims some members of the V8 team have been bragging a little bit about how V8 is “many times faster” than TraceMonkey. In fact, some guarantees may have been made.

Based on the data above, we’re running about 20% faster than V8 on SunSpider. While I’m sure there will be changes to each of the engines in the coming months I think that the claim that “many times faster” is ludicrous on its face and should be tempered by actual data. [ Note that the Google test is recursion heavy, something we're adding to TraceMonkey right now. This explains the gap on that one type of test. See Brendan's post above or John's post below for more details. ]

It’s also important to realize another fact. Google has had a small army of people working on the V8 engine for two whole earth years. We’re about 60 days into TraceMonkey and we’re already starting to match the performance characteristics of V8. As Brendan put it:

What spectators have to realize is that this contest is not a playoff where each contending VM is eliminated at any given hype-event point. We believe that Franz&Gal-style tracing has more “headroom” than less aggressively speculative approaches, due to its ability to specialize code, making variables constant and eliminating dead code and conditions at runtime, based on the latent types inherent in almost all JavaScript programs. If we are right, we’ll find out over the next weeks and months, and so will you all.

If you want data across browsers you should look at this post from John Resig that contains some graphics that give relative performance of various browsers including Safari, Firefox 3.0.1, IE, etc. His overview is great and gives a much wider view of relative browser performance.

Also as a side note because I have your attention. There are some bizarre and incorrect claims made in the comic about garbage collection. Brendan puts things right as a comment in John’s post:

@Ben: Chrome has a nice GC: exact rooting, generational with copying. Single-threaded, too (not an option for SpiderMonkey, which is used in AT&T 1-800-555-1212 and 411 AVR massively multi-threaded services built by tellme.com, now owned by Microsoft!). It definitely helps cut down on pauses and keep memory use flatter.

The Chrome comic book did have one piece of misinformation, though: it said other browsers’ engines use conservative GC, and have false positive problems because they can’t distinguish random integers from pointers into the heap. This is not true of Firefox, IE, or Opera.

We do live in interesting times.

September 03, 2008 05:15 PM

If you've been following along with the Chrome announcement, and you're interested in the whys behind their UI design, I refer you, gentle reader, to the Chromium Developer Documentation - User Experience, wherein is described

... the motivations, assumptions, and directions behind Chromium's user interface design. Its goal is to explain the current design in a way that further work can be developed in-style, or so that our assumptions can be challenged, changed, and improved.

Of course, the huge design choice that isn't explained, the giant in the room, if you will, shows up in this illustration from the comic:

I can't help but think that people will encounter some difficulties in using a browser that's taller than a man. The Fitts' Law hit alone seems worth a bit of rethinking on Google's part, at least without a lot of stretching.

September 03, 2008 03:38 PM

My friend Dan Schultz is currently taking a course called “Science of The Web”. For one of his assignments (see problem 2), he needs as much help as he can get. Here’s where you come in. It’s quick and easy:

1) Go to http://boom.aladdin.cs.cmu.edu/cgi-bin/ipaddy (the server might encounter an error, just refresh and it should work)
2) Enter ‘dschultz’
3) Get as many other people as possible to do the same

September 03, 2008 03:32 PM

September 03, 2008 03:00 PM

Well, I’m Back: Chrome.

Rob says it perfectly in just a few words.

September 03, 2008 02:40 PM

This is what you see when you visit about:internets. This is freaking awesome.

Years ago there was an idea to include the kitchen sink in Mozilla (you can view it here, not sure if that works in IE). It was a good idea considering it had everything else at the time.

I initially thought it was written using <canvas/>. I tried the typical view-source:, but in this case it doesn’t seem to work. The performance was really smooth with minimal CPU, more than <canvas/> typically allows. Now I was curious.

Then looking at the source it became obvious in about 0.1 seconds:

PathService::Get(base::DIR_SYSTEM, &path);
file_util::AppendToPath(&path, L"sspipes.scr");

It’s using the actual Windows screensaver (which is why it doesn’t work in Vista I presume). I hope for the Mac and Linux port they bundle jwz’s excellent XScreenSaver. Due to jwz’s impact in browsers and open source, I think there would be even better easter egg. From a quick look at the code it seems it’s not hard to do since every tab is it’s own process, it’s essentially just running the process inside the view.

For those who don’t understand why this is all so amusing, read this Wikipedia article about the “Series of Tubes“. It will only kill a small percentage of brain cells since it’s just the Wikipedia article explaining it. There are other Tubes references as I mentioned last night.

Thanks to those who left a comment in my last post for pointing this out.

By the way, check out Brendan’s post on TraceMonkey performance. He did a better comparison at actual JS performance. I only looked at selectors really quick.

September 03, 2008 01:47 PM

Brendan’s Roadmap Updates: TraceMonkey Update.

update from Brendan on our JS engine work. it’s fast with lots of headroom in the future. good times.

September 03, 2008 01:15 PM

Hello Community Testers!

The time is coming again for our Testday. Join us Friday, September 5th, 2008 in #testday on IRC from 7am - 5pm PDT.

This time we will concentrate on no less than 3 releases!

read more

September 03, 2008 12:59 PM

Focus for this bug day is Patch Love. Over 200 bugs have patches where
the bug appears to be stuck and is not progressing to being resolved.
With a little Love (attention), we expect that many of these bugs might
still get fixed in Thunderbird 3.

Patch Love is triaging. so coding experience is not needed. 1960s
clothing for this Love Fest is optional. Help is available on IRC should you need advice
about how to assist in a bug.

read more

September 03, 2008 11:35 AM