Both ears are now quite clearly up.

The Release Engineering:Future bugzilla component alternately inspires feelings of sadness, loathing, and contempt…and that’s just within the RelEng team!

I’m certain most developers first response to having their bug moved to the Future queue is, “Oh, look, my bug has fallen down a well.” Historically speaking, that may not be far from the truth.

What goes in Future?

Why does the Future component make people get punchy? For a long time, the Future component has lacked a decent description, so developers don’t know what it means when their bugs are moved there. Many have started hording their gigawatts in anticipation.

Bugzilla currently has the following small description of the Release Engineering:Future component:

“For longer term projects that have been agreed should be done, but have no immediate plans to so. These are not be part of the regular recurring triage. Advanced planning and placeholder goals for next quarter also go here.”

Despite the grammatical errors, this description is mostly accurate, but what does it actually mean:

• Triaged bugs with no immediate owners go here.
• Sadly, most enhancement bugs end up here unless they will make the core release process better, more streamlined, etc. quickly.
• Bugs that are blocked on longer term projects in other groups go here until there is something for RelEng to do.
• Advanced planning and placeholder goals for next quarter (or later) also go here. That’s pretty self-explanatory.

Remember: this description is for the Future component ONLY. The RelEng team continues to pick up and work on bugs that need to get done on a daily basis.

I’m thinking about how to improve this description, and will get the description updated in Bugzilla once I have achieved some rough consensus. In the meantime, I’ve posted this description of the Future component in the wiki as an ongoing reference.

The (Ever-Increasing) Numbers

At the time of writing, the Release Engineering:Future component has 343 bugs in it. This number has grown steadily over the past year despite having more release engineers on staff, and having made a great many improvements to our release automation and our continuous integration infrastructure.

Our turnaround time for bugs in the Future component is also not stellar. At our urging, the Mozilla Metrics team recently started setting up a dashboard to give us various statistics on our Bugzilla usage. Bugs don’t get fixed in the Future queue, so it’s hard to make truly accurate assessments here, but there are a lot of aging bugs in there. According to the numbers, fully 50% of the bugs in the Future component are older than 1 month and more than 25% are older than 6 months. How this compares to other teams or areas, I can’t say, but it certainly makes me empathize with developers who feel their Future-ed bugs have gone walkabout.

If it makes you feel better in a sadistic way, the majority of bugs filed by RelEng team members go directly into the Future queue. We’re not overly happy about it either.

I have a way? Is that better than a plan?

Things are getting done, though. For example, over the past month, the number of non-Future, release engineering bugs that are actively being worked on has gone from a low water mark of 130 up to over 200 today. For comparison, over the same period, the total number of bugs in the Future queue has slowly crept up from a low of 302 to 323. Mozilla is growing along so many axes that sometimes it feels like keeping the increase in the number of Future bugs to a linear relationship rather than exponential one is an accomplishment in itself.

So how do we stop the increase and start wrestling the Future component back under control?

The first step is triage. Starting this Thursday, February 11th, the RelEng team is going to have bi-weekly triage meetings to specifically prune down the Future queue.

As part of the triage, we’re going to be touching every bug and updating the whiteboard field with searchable tags. Our goal here is to make it easy to find classes of bugs in the Future queue so that duplicates and overlap can be easily eliminated, and fixes can be batched as much as possible.

We’ll be keeping a list of the tags we’re using in the wiki in case you want to follow along.

There are some classes of bugs that we won’t be able to eliminate (e.g. future goals), but hopefully within a few months, we’ll have the Future queue back under control.

It won’t be a quick fix, but it’s one we’re committed to.

I’m a bad conference organizer.

Why? Because we opened the An Event Apart 2010 schedule for sales back in, um, flippin’ November, and I never mentioned it here. Cripes, I never even posted when we announced the lineup of cities. I could go through the great big long sob-story list of reasons why 2009 was really tough and blah blah blah, but when you get right down to it, I fell down on my job.

Okay. So. Time to correct that.

(deep breath)

Hey everyone, check it out: the complete tour schedule for An Event Apart 2010! Woohoooo!

1. Seattle: April 5-7, 2010 (yes, three days; more on that anon)
2. Boston: May 24-25, 2010
3. Minneapolis: July 26-27, 2010
4. Washington, DC: September 16-17, 2010
5. San Diego: November 1-2, 2010

We’ve got a pretty killer lineup, if I do say so myself. You can get the mostly-complete list from our opening-of-sales announcement last November. It lists the people we had confirmed at the time; there have been a few additions since then. Check out your city of choice to see who’s going to be there! (But always remember that speaker lineups are subject to change: speakers are people too, and life has a way of interfering with schedules. I myself had to withdraw from An Event Apart Boston last year due to a family emergency.)

The price to register for these two-day, one-track Events is the same as it was in 2009, and there are educational and group discounts available for those who are interested.

But wait, I just said “two-day” when the first show of the year is clearly three days. What gives?

Seattle is the site of our first-ever A Day Apart, a full-day workshop that can be attended on its own or as part of a full three days of Event Apart ecstasy. And the inaugural Day Apart will be nothing less than a detailed plunge into HTML 5 and CSS3 with Jeremy Keith and Dan Cederholm. Jeremy handles the markup; Dan gets stylish. It’s going to be fantastic. I’m going to be in the back of the room for the whole day, soaking up as much as I can.

If you want to attend just the workshop, it’s $399 for the whole day if you buy an early bird ticket (available through March 5th). The price goes up $50 when early bird ends, and another $100 if you show up at the door. But I wouldn’t recommend that last, because I don’t think there will be any tickets available at the door. Again: if you show up unannounced on the day of the workshop and ask to buy a ticket, we will most likely have to turn you away, because I expect that there won’t be any seats available.

On the other hand, maybe you’d like to experience more than just one day of AEA goodness. Maybe you’d like to go whole hog and attend both the two-day Event Apart and the subsequent Day Apart, soaking up all the knowledge and enthusiasm and camaraderie that typifies An Event Apart. And who could blame you? If you do that, then the total early bird price for all three days is $1,190, whereas buying the event and workshop passes separately would total $1,294. That’s right: you actually get slightly more than $100 off the cost of the workshop if you attend all three days, over and above the early bird discount. (Or you can think of it as getting $100+ off the cost of the conference. We’re not fussy.)

As it happens, these three-day passes have proved quite popular. So if you want to get your hands on one of those—or on any Seattle tickets, whether one, two, or three days—I wouldn’t wait too long. Our internal analyses suggest that there will come a time, some time before the doors open on April 5th, that the ability to buy a ticket will cease to be. It may even pine for a fjord or two.

As for the four shows that come after Seattle, well, they’re looking pretty popular too.

I know I say this every year, but I’m really excited about what we’ve got planned for the year. Jeffrey and I constantly and (we hope) consistently strive to create an event that we ourselves want to attend, and that’s absolutely true of the shows and workshop we have planned in 2010. I can’t wait to hear what the speakers and attendees have to share. Hope to see you there!

Postbox now integrates with the Mac OS X technologies and applications you rely on most to get stuff done. Here’s what’s new:

Mac Address Book Support
Postbox provides read and write support for the Mac Address Book. Keep all of your contacts in one location and sync them with your iPhone or MobileMe service.

Send Meeting Invites with iCal
Apple’s iCal can now use Postbox for sending calendar notifications.

Search for Mail Using Spotlight
Postbox provides full support for Apple’s Spotlight to search through message bodies, message header information such as To: or From:, and attachment names. 

Exchange Images with iPhoto
You can export photos directly from Postbox into iPhoto, and iPhoto will use Postbox to send photos as well!

Send Link from Safari
Easily send a web page link from Safari using Postbox. Very handy!

Lookup in Dictionary
Direct text-to-Dictionary lookups will help you quickly pick the perfect words.

Drag-to-Dock Message Creation
Dragging a file to the Postbox icon in the Dock will create a new message with the file attached.

Learn more about these new features and how to use them in our Quickstart Guide.

And now, with our new Refer-a-Friend Program, we’ve created an exciting way for you save on Postbox, or even get Postbox for FREE! See our Refer-a-Friend Program Page for details.

Our Refer-a-Friend Program is easy! Tell your friends about Postbox, and earn $5 each time someone purchases with your coupon code! Refer six friends and Postbox is effectively FREE!

Step 1 - Save $10 on Postbox!
Use your search skills. Find a coupon code to purchase Postbox for just $39.95 $29.95!

Step 2 - Share your Coupon Code
We’ll give you your own coupon code for “$10 Off Postbox.” Share it via Facebook, Twitter, your blog, email… anywhere.

Step 3 - Make $5 each time someone uses your code!
You get it - make 6 referrals and we’ll send you $30 - the price you paid for Postbox. Any more… and it’s all gravy.

There you have it. Postbox for about the price of a pizza, plus a way to earn it all back and give your friends a discount. Everyone wins!

To learn more, please see our Refer-a-Friend Program page, read our FAQ, or review the Terms and Conditions.

A special “Thanks!” to Charlie Wood of Spanning Sync for his help and advice on the development of this program.

Recently, I found that I needed my chrome Mochitest to wait for a XBL binding to apply, before continuing the test. For the end-user, waiting is hardly an issue - by the time they see the new user interface, all the bindings have applied. Mochitest (and most other automated test harnesses) runs straight through, and brakes for nobody. In some cases you can pull some trickery with nsIThreadManager, convincing Firefox to wait... but that's hardly reliable.

So I came up with a three-part solution.

1. Force my XBL bindings to fire DOM events when the constructor executes.
2. Break up my test functions into (slightly) smaller functions, each of which handles a part of the overall test. Two parts cover the main functional testing, while a third part is specific to the XBL binding.
3. Implement a generic testing harness for Mochitest which can manage the flow from one function to another.

This new test harness, which I call PendingEventsTest, adds a layer of complexity on top of SimpleTest. Each test function is added via PendingEventsTest.addTest(), and you can pause for a DOM event with PendingEventsTest.addEventLock(). The whole test sequence can abort with an error by calling PendingEventsTest.abortFail(). You can advance to the next test function in the sequence with PendingEventsTest.asyncRun() or PendingEventsTest.run().

There's more complexity to it than that, of course. To move data from one test function to another, I also added "payload" support, for storing a generic object. Also, this is written for chrome Mochitests - it will likely fail in content Mochitests. Still, this new test harness helped me finish support in Verbosio for my equivalent of the <xbl:children/> element in markup templates.

Lastly, it (and the logging service I wrote a few weeks ago) is licensed under MPL 1.1/GPL 2.0/LGPL 2.1, so anyone who wants to borrow this for Mozilla code is welcome to. Cheers!

One common thread running through the many different and interesting WebGL projects out there is that they all need to do vector and matrix math, do it quickly, and do it in JavaScript.  To date, developers have either rolled their own, or they've used Sylvester, a fairly featureful vector and matrix JavaScript library.

One of the problems with Sylvester is that while it's fully featured (arbitrary NxN matrices and vectors can be created and manipulated), it suffers in performance because of it.  Since this is such a crucial part of a successful WebGL program, I've put together a small package that I'm calling mjs.

mjs is designed around speed and simplicity.  For example, it doesn't attempt to stuff vectors and matrices into JavaScript objects.  Because the language offers no operator overloading, there's very little benefit in treating these types as discrete objects, and lots of performance and memory usage downsides.  Instead, it provides a set of functions for performing operations on vectors and matrices, which can be any array-like object.  For any function that returns a vector or matrix, an existing array can be passed in to take the result, or the function can create a new one.  Array reuse ends up being important because of the potential for expensive garbage collection churn eating away at performance.

Here's a sample of the API:

var r = M4x4.rotate(Math.PI/2, V3.$(0, 1, 0),  M4x4.I);

Note that V3.$ and M4x4.$ are shorthand for creating a new V3 or M4x4 (I wanted to use V3() and M4x4(), but that didn't work out too well since functions have a length property).  However, because all they return are just new array-like objects, you could also write:

var r = M4x4.rotate(Math.PI/2, [0, 1, 0], M4x4.I);

If the WebGL types are available, those will be used for newly created vectors/matrices.  They are a significant performance boost especially for repeated operations; but for specifying one-off vectors such as the above, literal array syntax is fine.

The rotate function internally makes a rotation matrix, and then multiplies it by the given matrix.  So the above could also be written as:

var rotation = M4x4.makeRotate(Math.PI/2, [0, 1, 0]);
var r = M4x4.mul(M4x4.I, rotation);

(The last line being redundant given that we're multiplying by the identity matrix.)

All methods that return a vector or matrix take an optional final argument, that of an existing object to reuse.  For example:

var m0 = M4x4.$();
r = M4x4.mul(someMatrixA, someMatrixB, m0);
// r == m0, so the assignment isn't necessary, but it's handy for chaining
// .... do something with r ...
r = M4x4.mul(someMatrixB, someMatrixC, m0);
// r == m0 still
// ... do something else with new results ...

Without allocating any additional temporary objects.

As mentioned before, one of the goals of mjs is performance.  Matrix multiplication is one of the most common tasks, so here are some numbers comparing mjs, Sylvester, and native C code.  This was run on a Core i7 desktop using a local build of Spidermonkey, which included one patch that's about to go into the tree that fixes the no-reuse tracing case.  (Without it, the no-reuse tracing case is much larger because it's never actually jitted.) The test is simple: it multiplies two matrices together in a loop 1,000,000 times.

(I also have numbers for MSVC without the SSE2 compile flag, but the numbers vary greatly depending on whether the values eventually go to infinity or not; if the values end up trending towards 0, the non-SSE2 code tends to win at around 52ms vs. 71ms; if the values trend to infinity, the non-SSE2 code takes around 11,000ms!)

Those numbers are pretty encouraging -- having native code be only 2x as slow for something like this is pretty nice to see. Granted, this is only a very isolated test, and I'm sure there are some tricks to optimizing the native code case (it's currently just a fully unrolled set of multiplies and adds). The "no JIT" case is less nice, but I'm sure that our Jaegermonkey folks will be all over this testcase (right, guys?). In any case, ideally most WebGL rendering loops will be fully traced in Firefox, so it would be less of an issue.

mjs is still very much a work in progress; it's missing a test suite and a whole bunch of features. You can find it hosted at Google Code, at webgl-mjs. (Side note: I couldn't just call the project mjs because a project called mjs was abandoned on Sourceforget 5 years ago, and Google Code complained.) There's also some documentation, viewable online here.

Bugs and contributions welcome!

Thanks to hard work by a whole bunch of folks, we shipped Lanikai Alpha 1 (the first development release of Thunderbird after 3.0) yesterday. More details about Lanikai can be found on the project page.

This release is a first in several notable ways:

* we're now requiring automated tests to land with most code changes
* the release cycle was much shorter than any development release in recent memory
* we're now having to do development and releases across both a development and a stability branch.

We've already learned a bunch of stuff from all the changes, and I expect that learning to continue for a little while before we're fully in a groove.

Thanks to everyone who has been part of making the release happen!

A common situation I run into is that I have some testcase, I profile it, then I optimize one of the things that looks slow a bit and reprofile. If I'm lucky, then the fraction of time it takes drops from B to A (A < B of course, with B standing for "before" and A for "after"). What does that mean for the overall time of the testcase?

Obviously, what it means depends on both A and B. If we assume that the time taken for the part that wasn't optimized hasn't changed, then the overall speedup is (1-A)/(1-B).

So B - A = 5% would mean a 2x speedup if B is 95% and A is 90%, and only a 1.05x speedup or so if B is 5% and A is 0%. If B is something like 53% and A something like 48%, then you get a 1.11x speedup.

All of which is to say that focusing on the hotspots is _really_ the way to go, if at all possible.

This is a follow-up to Ben’s blog post about the RelEng Sheriff back in October. His post described clearly what the RelEng Sheriff (and more generally, the RelEng team) can do to help developers.

Since we implemented the RelEng sheriff (or “buildduty” as it is more informally called) last spring, developers have been getting better about using the buildduty person as the first point of contact for RelEng issues. I’d like to implore people to continue doing so. There are a few exceptions, of course:

• It is outside of regular work hours and/or the designated buildduty person is not available; or,
• you are already working on a bug with a specific release engineer.

We recognize that different release engineers have different core competencies, and it may be tempting to go “straight to the source,” but please respect our process. The process is in place to limit (as much as possible) the interrupt-driven nature of release engineering work and to minimize the impact of those interrupts on ongoing projects. In many cases, the person with the expertise you need will still end up helping you (we’re all in the same IRC channels, after all), but the buildduty person is specifically committed to helping you, even if only as a thin scheduling proxy for another release engineer.

Ben’s post had a good list things that RelEng can help developers with. Based on actual requests over the past few months, here are a few other services we can offer:

• clone a virtual machine for one-off debugging/testing: Sometimes patches work on the try server but (for whatever reason) don’t once checked in. Sometimes tests fail or are intermittently orange. If you’re seeing issues like these after landing a patch, or need access to a specific platform for short-term work, the RelEng team can clone one of our reference machines and give you access (under certain circumstances).
• grab build/extra logs from a build machine (provided they exist). This is often useful if a try server build generates extra, non-standard output

In both the above cases, the best thing to do is talk to the person on buildduty and then file a bug.

Conspicuously missing from Ben’s post was a list of what RelEng can’t do for you. While we can usually point you in the right direction, there are some things that we explicitly cannot do:

• help you debug issues with your own local builds. We’re not (necessarily) build config experts, so unless you’re running with exactly the same configuration as our build machines and don’t have any code patches applied, you’d be better served asking the talented folk in #developers or posting to the newsgroups (m.d.builds or m.d.a.firefox)
• shepherd your patch through the landing process. Standard patch landing rules apply: *you* are expected to be around when you land patches. If builds/tests fail and you’re not around, your patch will likely be backed out.

Need help finding the RelEng sheriff? Here’s the RelEng sheriff schedule.

This is the third in a series of blog posts (previous: 1, 2) on how Mozilla is using its trademarks to try and make sure everyone gets a genuine copy of our software, for free.

Mozilla has a form where people can report sites abusing our trademarks. And we are very grateful to people who do. Harvey Anderson, the Mozilla general counsel, has recently posted some statistics on what those sorts of reports have helped us achieve.

But we aren't the only people trying to deal with the problem of "subscription trap" sites. downloados.de is a private initiative in Germany educating internet users about the typical set-up of a subscription trap. It comes across like a typical trap site, but when the user makes the final click to send off their personal details and to obtain the software, the website then informs them that they were about to spend money on free software and that they should be more careful next time.

Sodapop turns 9 weeks old tomorrow. The most notable change from a week ago is that one of her ears has started to stand up. Eventually (probably in a week or so) both will be standing tall. The next change, besides weight gain and better manners, will be when more of her silver hair comes in. You can see a bit of it around her eyes, but she's still mostly black and tan.

Sodapop at 8 weeks

Sodapop at 8 weeks 6 days

For those people paying attention (and anyone who might want to update my Wikipedia entry,) Sodapop the yorkie is the third child in our family behind Ptolemy the cat and Munch the bunny.

It's been a while since I posted a progress update (or really any blog post, ahem), but porting Firefox/Fennec to Android is progressing at a good clip. After working out a few kinks (and setting the all-important "you're allowed to touch the network" permission), I just got our first page load:

Mouse events sort of work, toplevel windows sort of work, keyboard doesn't work yet but shouldn't be hard to hook up.  This is running in an emulator at the moment for ease of debugging, but it's working just fine on physical hardware as well.

You'll note that this is the full Firefox interface, and not the Fennec/Firefox Mobile UI; we're testing with the full interface because it's significantly more complex than the mobile UI and stresses Gecko much more.  So, if the full UI works, then Fennec should work fine as well.  Given the interest in Android on netbook and tablet devices, an updated version of the full Firefox UI might find a home on some of these.  Android has been pretty great to work with so far; it's a bit unusual platform for us due to its Java core, but with the NDK we're able to bridge things together without many problems.

We're still a ways  to go before any kind of usable alpha release, but we're certainly one step closer.  We'll also be able to accelerate our progress now that we have some of the basic scaffolding in place.  I know I'm looking forward to running Fennec on my Droid, and there are tons of Android devices coming out that should be great platforms for Fennec.

The Mozilla Store needs your help! If you have a minute, please take this quick survey

This is the second in a series of blog posts (previous) on how Mozilla is using its trademarks to try and make sure everyone gets a genuine copy of our software, for free. I will continue to use Germany as an example.

When we discover a wilful trademark infringement, we normally take the following steps, in increasing order of seriousness:

1. Contact search engines to ask for the site to be delisted.

We have a good relationship with the major search engines, and being delisted or having their advertising removed does a great deal to "cut off the air supply" of fraudulent sites.

2. Report the site to consumer protection agencies such as computerbetrug.de, antiabzockenet.blogspot.com and boocompany.com.
3. Send a cease and desist letter.

In most cases, sending a C&D; sorts out the problem. If it doesn't, we:

4. File a DENIC domain dispute and request cancellation or transfer of any infringing domain names.

Where there is a domain name involved which infringes Mozilla’s trademarks, we can file a domain dispute alongside sending the C&D.; For German domains, this is very quick and cost-efficient (national stereotypes at work :-). Upon cancellation of a .de domain by the infringer, DENIC automatically transfers the domain to Mozilla. (For other TLDs, it's not so automatic.)

We have already obtained numerous domain names this way. Examples include "mozilla.de", "mozilla-europe.de", "mozillamessaging.de" and "mozilla.fr", as well as dozens of typosquatted domains.

Unfortunately, for subscription traps, a C&D; rarely has any effect. So we move on to:

5. Obtain a preliminary injunction (PI).

In Germany, PIs are also quick and cheap. Typically, it takes 1 or 2 days to obtain a PI. The proceedings are ex-parte (you only need one side in court), the other side is not even notified of the application for a PI and there is no discovery of evidence. You make your case, and the judge decides.

PIs become effective upon service. If they are not complied with, they can be enforced through penalty payment proceedings. However, a quicker way to take the site down is by approaching the provider. Under German law, internet providers are liable for infringing content once they are made aware of the infringement. Thus, a letter to a provider, accompanied by a copy of the PI, usually leads to the immediate shutdown of the site. (Remember, the site has already been warned of proceedings by the C&D; this is not coming out of the blue.)

So far, Mozilla has needed to file 6 7 (another one this week) PIs, and all of them were successful. In two cases, the other side appealed, but the PI was confirmed on appeal.

I've just finished watching Diederik van Liere's fascinating presentation (Ogg video, 20 mins), linked to by Mark, about his work with bugzilla.mozilla.org data. Download the full slide deck - you'll need it to follow along with my comments, which should be of interest to the community-minded.

Slides 9 and 10, the community dynamics slides, are worrying. Diederik explains the decline in the size of the community as "increased product maturity", but I'm not sure that's true. If it were, we would expect to see the number of people entering the community decreasing. However, that number has stayed roughly constant, with peaks surrounding a release as we reach out to beta testers, and as new users report bugs. It's the number of people leaving which seems to be increasing. Fewer people are hanging around once they get here. And I don't know why.

Slide 11, about what the final resolutions ended up being of bugs filed in each year, is fascinating. It would be really interesting to see that graphed at a greater granularity.

We have made significant progress in reducing the percentage of duplicate bugs filed. People complain about Bugzilla's search, but the percentage was a flat 25% from 2002-2004, and it's now a flat 13% - basically half what it was. Also, from a low of 34% of bugs filed being FIXED, we are now up at 56%.

There are no doubt lots of factors involved in this effect, including the reduction in the size of the community mentioned in the earlier slides. I'm really interested in working out what we might have done which has improved the situation. I have an utterly open mind on this. here are some significant events I can think of which may be relevant:

• 2000-10: duplicates.cgi created
• 2002-10: Bugzilla Helper created
• 2003-09: Specific search created
• 2004-12: Hendrix created

Can anyone else think of other events or software deployments which may be relevant? I'm happy to do the research to find out when they happened.

The awesome Jeremy Orem has written a Mediawiki extension to allow the direct embedding of Open Video, and has turned this feature on on wiki.mozilla.org. Check out my demo page (you just type the normal HTML syntax into the wiki markup) and then feel free to use it to host Mozilla-relevant videos. (Note: wiki.mozilla.org has a 32MB file upload limit.)

In a follow-up to my previous post, here's an example of what can happen if your build your business on non-free data or software from a single supplier:

Nav4All navigation shut down by Navteq

Letter to 27,625,631 Nav4All navigation customers

Dear Customers,

It is with the deepest regret that we hereby notify you that the global navigation of Nav4All and the Tracking & Tracing will go offline in 3 days. The reason for the same is that the data licence agreement with Navteq (a 100% Nokia subsidiary) was not extended, in a totally unexpected manner. ...

Nav4All worked on "hundreds of different mobile telephones of many makes such as Blackberry, Sony Ericsson, Samsung, Motorola, Android, HTC, Nokia, LG, Iphone, Ipod etc." Navteq is now owned by Nokia. It's not hard to join the dots. I'm somewhat surprised Nav4All call this "totally unexpected", though. It's the obvious thing for Nokia to do. And they bought Navteq over two years ago. If I were a Nav4All shareholder, I'd be having strong words with the management right now...

Software freedom means never having to say "I'm very much hoping Apple continues to allow...".

And that's all you'll hear from me about the iPad :-)

Last week, I wrote about a new logging infrastructure I built to track down a bug. In the original post, I warned that logging wasn't a panacea - that it could cause more trouble than it solved. I was more right than I knew, as I added a bit of logging which led inexorably to a crash by JS_ASSERT failure. (For those who don't know what a JS_ASSERT is, it's an assertion inside the JavaScript Engine that all is well. Since JavaScript is one of the primary languages of the World Wide Web, these assertions are really important. If JavaScript is misbehaving, it can't be trusted. Fail one such assertion, and the program aborts, forcing the developer to take notice.)

At first, the crash didn't make a damned bit of sense. I prefer to write JavaScript, not just because I entered into software engineering (and Mozilla development) through JavaScript, but also because it's super-stable. In fact, the only new code I was introducing was in JavaScript. It shouldn't crash. Through an unlikely chain of events, it does.

This article details how I was able to analyze the crash itself, how logging set up the conditions for the crash, and how other logging ultimately proved that the crash resulted from a logging call. I've filed this as bug 543304. Ultimately, reducing this test case to a usable bug report will not be easy - but worth it. More details in the extended entry. (Warning: technobabble content ratio is high. If you do not want to see how this developer thinks and debugs Mozilla code, do not read on.)

Five Mozilla people at the top of Mt Ruapehu 12 days ago. The crater lake is in the background.

According to Google's Enterprise Blog, Google is starting to phase out IE6 support, starting with Google Docs and Google Sites by March 1st. While this won't affect the big enterprises (who probably don't use those Google services much), this is a good first step and as more follow IE6 in the enterprise will finally die.

I took another stab at directly cross-compiling (not via distcc) using toolwhip. My previous attempt failed, but not due to libffi at all. The problem there was that I had the Mac ld in my path before the host ld. After fixing that and a few mozilla build system issues and making sure the build system can find the right SDK and the right ar and such I now have a cross-compile setup working. No make package yet, since that requires the dmg-creation utility which I don't have on the Linux machine. No --enable-breakpad support yet due to bug 543111. --enable-shark needs headers I don't have on that machine yet, so I'd need to sort that out. But for basic bisecting, this works.

Just so I can find it later, the working mozconfig file I'm using is something along these lines:

mk_add_options MOZ_MAKE_FLAGS="-s -j10"
export MOZ_MAKE_FLAGS="-s -j10"

mk_add_options CC="ccache /Developer/usr/bin/gcc-4.2"
export CC="ccache /Developer/usr/bin/gcc-4.2"

mk_add_options CXX="ccache /Developer/usr/bin/g++-4.2"
export CXX="ccache /Developer/usr/bin/g++-4.2"

mk_add_options CROSS_LIB_PATH="/Developer/usr/lib:/Developer/SDKs/MacOSX10.5.sdk/usr/lib"
export CROSS_LIB_PATH="/Developer/usr/lib:/Developer/SDKs/MacOSX10.5.sdk/usr/lib"

mk_add_options CROSS_COMPILE="1"
export CROSS_COMPILE="1"

export LD=/Developer/usr/bin/ld
export AR=/Developer/usr/bin/ar

mk_add_options PATH="/home/bzbarsky/bin:/usr/lib64/qt-3.3/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib64/ccache:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/Developer/usr/bin:/Developer/SDKs/MacOSX10.5.sdk/usr/bin"
export PATH="/home/bzbarsky/bin:/usr/lib64/qt-3.3/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib64/ccache:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/Developer/usr/bin:/Developer/SDKs/MacOSX10.5.sdk/usr/bin"

ac_add_options --target=i686-apple-darwin9
ac_add_options --enable-application=browser
ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.5.sdk
ac_add_options --disable-crashreporter
ac_add_options --disable-optimize
ac_add_options --enable-debug
ac_add_options --disable-tests

Various other --enable-whatever are hanging out in there too, but the above are sort of the minimal set one needs at the moment.

Recently the German government, along with the governments of several other countries, recommended (link in German) moving away from IE to "an alternative browser", due to some well-publicized IE security flaws. Blog of Metrics has shown us the effect this recommendation has had on downloads of the German localized version of Firefox - 300,000 extra copies in one weekend.

Unfortunately, we strongly suspect not all Germans will be getting the real deal. Germany is a place where Mozilla has a particular problem with trademark infringement of various types. The most typical of these are:

• infringing domain name registrations (e.g. typo domains such as "morzilla.de", "firfox.de")
• misleading online content (people pretending to be the official Mozilla download site)
• offers of modified versions of Mozilla’s software, e.g. with a changed toolbar, or containing malware
• "subscription traps" - where something which seems free actually ends up costing you

I've written about subscription traps in the past. These are fraudulent websites which lead users to believe that they are obtaining a typical free download of Firefox or Thunderbird. Only the small print mentions that by registering for the download, the user undertakes a contractual obligation to pay up to £95 (€105; US$150) per year.

This sucks.

Over the next few days I'm going to be blogging about what Mozilla is actively doing to use our trademarks to protect Germans, and residents of other countries as well, from being ripped off in this way.

My thanks to Anthonia Zimmermann of Lovells for her help in preparing this series of blog posts.

I've seen a number of comments recently along the lines of "I'm in Europe, so the H.264 patents don't apply to me; why are you not letting me have a browser that plays my Youtube videos?" So I took a look at the list of patents on H.264. Or rather, the first 6 pages of the 43 page list. Excluding the US, there are relevant patents granted in at least the following countries:

• Europe: Germany, France, UK, Finland, Italy, Sweden, Belgium, Bulgaria, Liechtenstein, Austria, Czech Republic, Denmark, Spain, Hungary, Ireland, The Netherlands, Poland, Romania, Portugal, Slovenia
• Asia: Japan, China, South Korea, Hong Kong, Singapore, Taiwan, India
• Americas: Canada, Mexico
• Australia

I wasn't reading very carefully; I'd be suprised if I didn't miss a few, or if a few more don't come later in the list somewhere.

It's not quite Spring yet, but with the release of Firefox 3.6, now would be a great time to give your browser a good cleaning.

First, make sure you're on the latest Firefox. In the Help menu, select Check for updates... and apply any updates offered.

Next, let's look at your extensions. Go to Tools -> Add-ons... and select the "Extensions" tab. Scroll through your list of extensions and if you see one that you're not using regularly, go ahead and click the Disable button. This won't remove the add-on, it'll just stop it loading up when you start Firefox. You can always re-enable it if you decide you need it back. Next, look and see if you have any extensions that you disabled in the past that you probably won't be using again. Let's remove those. Simply click the Uninstall button.

Go ahead and restart Firefox at this point. You might already notice a big speed-up in Firefox's start-up time.

Now that we've taken care of extensions, let's look at your plug-ins. Plug-in vendors are notorious for adding plug-ins to Firefox without asking you so you might have a few there you don't need or want. To check, go to Tools -> Add-ons again. This time, select the "Plug-ins" tab. Scroll through that list. In my experience the only plug-ins that are really useful are Flash and Silverlight. (and the "Mozilla Default Plug-in"). Unless you know you need it, go ahead and disable any other plug-ins in the list. This will probably help Firefox perform better and certainly keep you safer. You can always re-enable the plug-in if you find that you need it later.

Go ahead and restart Firefox so these plug-ins get unloaded from your browser.

One final clean-up I like to do is to "vacuum" my history and bookmarks database. There is an extension called Vacuum Places that makes this really easy. Once you install the extension and restart Firefox, you should see a button in your statusbar that will trigger the clean-up. You should only have to do this once (and you can then disable or uninstall the add-on) because Firefox 3.6 now does its own periodic cleaning. This will just give you a jump so you don't have to wait on Firefox to do it automatically.

With those simple steps, you'll probably have a much faster, more stable, and overall happier Firefox.

FOSDEM 2010, the premier grass-roots open source conference in Europe, is fast approaching. Every year, I try and persuade the organizing committee to reduce the number of Mozilla talks so that I can take the time to see what other free software projects are up to. Particularly as we had MozCamp EU last year, I hoped that this year it might actually happen. But, as in every previous year, they have managed to find too many interesting people with interesting things to say :-( Ah, well. As well as all of them, I'll be giving a fast Foundation update, and doing a lightning talk on the Bugzilla API.

Speaking of which: if you are coming, and would love (a maximum of) 5 minutes to tell the Mozilla community about your latest project or ask for help with an upcoming idea, then why not propose a lightning talk of your own?

Recently, Vimeo and YouTube announced that they were moving to support the HTML5 video tag, as DailyMotion did last summer. This is an important step in making video a first-class citizen of the modern web, and that is great news. Unlike DailyMotion, however, Vimeo and YouTube chose to rely on the patented H.264 video encoding, rather than an unencumbered encoding like Ogg Theora. This means that the <video> pages on those sites will not work with Firefox.

Vimeo and YouTube seem to believe that reliance on proprietary plugins for video is a problem on the web. Mozilla believes that reliance on patent-encumbered formats is a problem on the web. Who’s right? Both groups are, in this case; that we can attack, from different perspectives, the multifacted problem of freeing video on the web is an example of the distributed innovation that has made the web such a powerful and popular platform.

For Mozilla, H.264 is not currently a suitable technology choice. In many countries, it is a patented technology, meaning that it is illegal to use without paying license fees to the MPEG-LA. Without such a license, it is not legal to use or distribute software that produces or consumes H.264-encoded content. Indeed, even distributing H.264 content over the internet or broadcasting it over the airwaves requires the consent of the MPEG-LA, and the current fee exemption for free-to-the-viewer internet delivery is only in effect until the end of 2010.

These license fees affect not only browser developers and distributors, but also represent a toll booth on anyone who wishes to produce video content.  And if H.264 becomes an accepted part of the standardized web, those fees are a barrier to entry for developers of new browsers, those bringing the web to new devices or platforms, and those who would build tools to help content and application development.

Some companies pay annually for H.264 licenses, which they can pass on to users of their software. Google has such a license, but as they have described, it does not extend to people building from their source or otherwise extending their browser. (Apple and Microsoft are licensors to the MPEG-LA’s AVC/H.264 patent pool, so their terms may differ substantially.) Personally, I believe that it is completely their right to make such a decision, even if I would prefer that they made a different decision.

Mozilla has decided differently, in part because there is no apparent means for us to license H.264 under terms that would cover other users of our technology, such as Linux distributors, or people in affiliated projects like Wikimedia or the Participatory Culture Foundation. Even if we were to pay the $5,000,000 annual licensing cost for H.264, and we were to not care about the spectre of license fees for internet distribution of encoded content, or about content and tool creators, downstream projects would be no better off.

We want to make sure that the Web experience is good for all users, present and future. I want to make sure that when a child in India or Brazil or Kenya discovers the internet, there isn’t a big piece of it (video) that they can’t afford to participate in. I want to make sure that there are no toll-booth barriers to entry for someone building a whole new browser, or bringing a browser to a whole new device or OS, or making and using tools for creating standard web content. And I want that not only altruistically, but also because I want the crazy awesome video (animation, peer-to-peer, security, etc.) ideas that will come from having more people, with more perspectives, fully participating in the internet. The web is undeniably better for Mozilla having entered the browser market, and it would have been impossible for us to do so if there had been a multi-million-dollar licensing fee required for handling HTML, CSS, JavaScript or the like.

I very much believe that Google (both the Chrome and YouTube teams), Vimeo and many others share our desire to have a web with full-featured, high-performance, unencumbered, natively-integrated video, and I look very much forward to us all working — together and separately — towards that end.

People have raised questions about using existing support for H.264 (or other formats) that may already be installed on the user’s computer. There are issues there related to principle (fragmentation of format under the guise of standardized HTML), to effectiveness (about 60% of our users are on Windows XP, which provides no H.264 codec), to security (exposure of arbitrary codecs to hostile content), and to user experience (mapping the full and growing capabilities of <video> to the system APIs provided); I’ll post next week about those in more detail, if others don’t beat me to it.

I was recently honored to be asked to be a judge for the MIX 10k Smart Coding Challenge, running in conjunction with Microsoft’s MIX conference. The idea is to create a really great web application that totals no more than 10KB in its unzipped state.

Why did I agree to participate? As much as I’d like to say “fat sacks of cash“, that wasn’t it at all. (Mostly due to the distinct lack of cash, sacked or otherwise. Sad face.) The contest’s entry requirements actually say it for me. In excerpted form:

• The entry MUST use one or more of the following technologies: Silverlight, Gestalt or HTML5…
• The entry MUST function in 3 or more of the following browsers: Internet Explorer, Firefox, Safari, Opera, or Chrome…
• The entry MAY use any of the following additional technology components…
  • CSS
  • JavaScript
  • XAML/XML
  • Ruby
  • Python
  • Text, Zip and Image files (e.g. png, jpg or gif)

Dig that: not only is the contest open to HTML 5 submissions, but it has to be cross-browser compatible. Okay, technically it only has to be three-out-of-five compatible, but still, that’s a great contest requirement. Also note that while IE is one of the five, it is not a required one of the five.

I imagine there will be a fair number of Silverlight and Gestalt entries, and I might look at them, but I’m really there—was really asked—because of the HTML 5 entries. By which I mean the open web entries, since any HTML 5 entry is also going to use CSS, JavaScript, and so on.

The downside here is that the contest ends in just one week, at 3pm U.S. Pacific time on 29 January. I know that time is tight, but if you’ve got a cool HTML 5-based application running around in your head, this just might be the time to let it out.

Help -> Check for updates...

Or, if you're on some other browser, just head over to getfirefox.com

Today, nearly 150 software developers are participating in Indie+Relief, an effort to help the people of Haiti who are in desperate need of aid. Proceeds from today’s sales will be donated to a variety of charities and support organizations, such as the American Red Cross, Doctors Without Borders, UNICEF and more.

Visit Indie+Relief today to purchase some terrific software and to help those in need.

For reasons that aren't material to this rant, I'm trying to get a T-Mobile SIM card set up with T-Mobile's ridiculously named "Even More Plus 500 Talk + Text + Web" plan. At this point I have a SIM card, and after much pain and suffering in phone conversations and online chat support, I have an account that is fully paid up.

Let's log in to the "My T-Mobile" site's "Billing & Payments" page to see how much I currenly owe:

Ok it says I owe $62.42 by 1/19/2010 (today) for service from 2/9/2010 - 3/8/2010 (next month). But it also says that my monthly charges for my previous bill are $127.42 due on 3/9/2010 (two months from now).

None of those numbers seem to add up to $59.99, which is what the "Even More Plus 500 Talk + Text + Web" plan is advertised as costing, but I suppose $62.42 could equal $59.99 if one were to imagine that T-Mobile felt they could put a few "fees" on there that for whatever reason could be assumed not to count. But what's with the $127.42? And what's with the due dates? Let's click "See details" to see details:

Wait, bill summary? I wanted details! And hold on, this page says my account balance is $0.00, and that I paid $62.42 on 1/20/10 (tomorrow). It also gives my monthly charges twice... once as $0.00, and once as $127.42! I guess if you average them it adds up to $63.71, which is similar to $62.42...

Oh look, the details are below the fold.

This says the next service period is $63.71, that they've received $62.42, that the previous balance was $63.71, and that they "adjusted" my account by $65.00 (the result of my calling billing support because they hadn't applied the $63.71 they actually charged me to my account), and apparently that all adds up to me owing $0.00... by 02/05/2010.

Clearly maths is not their strong point. Also not their strong point: being consistent about how they mark up dates. Or how they decide what dates are important.

Oh and... also not their strong point: matching reality. So far they've only actually charged me $63.71, once, though I have in fact tried to pay more than once (earlier today I also tried to pay the $62.42 that some of these pages claim I owe, though my bank has yet to see that charge).

Still, the $127.42 is a bit confusing. Let's see what the "View Bill" button under that number brings up.

Whaaaa!? FPEvenMorePlus 500TTW $119.98? What on earth is that? "Amount due 2/05/10: $127.42"? That completely contradicts the previous page! How much do I owe on that day, $0, or $127.42??

They say the way to work out how much you owe is to dial #225# from the phone, so let's try that... Ok, that says $0. I guess the phone would know best.

I give up trying to work out how much I owe; let's instead try to get the "Unlimited Data" working on this phone. I've heard rumours that one has to buy a $0 optional extra "Unlimited Web" service since otherwise the "Even More Plus Unlimited Web" is actually limited. Add additional services on this line... Internet & E-mail... Aha, here we go. "T-Mobile Smartphone Unlimited Web with FlexPay". That sounds promising. And it's free! Just like the rumours. Let's "buy" that and quickly review the charges:

Added plan and services... $0, yup. Unchanged plan and services... $59.99. Yup. So, the grand total is... $89.99. Wait, wait, hold on, let me recheck the maths here... $0... plus $59.99... carry the one... What??

Ok, ok, clearly it got confused. Let's close the browser and start over. Add additional services on this line... Internet & E-mail... "T-Mobile Smartphone Unlimited Web with FlexPay". And it says FREE. So we click it again, and let's see how much $59.99 + FREE equals this time:

TEN THOUSAND AND EIGHTY EIGHT DOLLARS AND NINETY NINE CENTS?!

I give up. I'll try calling them tomorrow.

Today Arlan happened to look at my screen when part of the desktop was actually visible. That led to approximately the following conversation:

Arlan:

Папа, там лиса!

Me:

Где? Да, там лиса.

Arlan:

Еще лиса! Две лисы.

Me:

Две?

Arlan:

Один, два, три.... Три лисы!

Little did he know that the fourth one (3.5 to be exact) was hiding under the iTunes window....

First off, thanks to everyone who took the time to reply to my original blog post. Several people pointed me to moz4js, and I'm quite pleasantly surprised to find out the Mozilla Thunderbird team uses it quite a bit. I hadn't heard of it, but when I did through the comments, I found it had the same problem NSPR logging has: single language support.

Then I realized: if we put moz4js in a JavaScript module, then a component can reference that module and expose the same interfaces to XPCOM. Chrome JS and JS components can load the module, and all other languages can use the XPCOM component. Maybe not simple, but certainly workable.

No, I'm not signing up to own the toolkit moz4js bug. I'm not wholly convinced, personally, it's the right way to do logging. What I do think, though, is that we need a general discussion on logging API's and consumers.

In the bug, Flock mentioned their own API - which I also didn't know about. I mentioned Skyfire has an internal logging system. It makes me wonder how many other companies and projects (Songbird, Komodo, Disruptive Innovations, etc.) have implemented their own logging API's. This is one subject that reasonably affects the whole Mozilla developer community.

If MozPad were still active, this is one subject I'd put right to them and develop a standard logging API for. Since we don't have MozPad anymore, I would like to put it to the community at large:

1. What do you require logging for?
2. What logging capabilities do you need?
3. What logging infrastructure (API, code) have you already implemented or used?
4. What tests exist and pass for the logging infrastructure you use?
5. How extensively do you use your logging infrastructure?
6. How easy is it to work with your logging infrastructure?
7. If you use someone else's logging infrastructure, what's missing?
8. Are you willing to work on getting your logging infrastructure into the Mozilla code base? (Writing code, tests, specifications)
9. Are you willing to work on developing a common Mozilla standard logging API and infrastructure, and getting that into the Mozilla code base? (Writing code, tests, specifications)
10. Are you willing to actively "own" and drive an effort towards adding a Mozilla standard logging API to the Mozilla code base?

Please reply in the comments. The quality and quantity will tell me how seriously I should be taking this.

(P.S. I found a bug in my logging interfaces already. Not the JavaScript code, but the IDL. Bonus points to the first person to spot it besides me - it's a little undocumented gotcha.)

Just a few days after the German government warned users off of Internet Explorer, the French government has done the same.

Yes, all browsers have flaws, some of them security flaws. But IE has a known flaw that has been weaponized. There have been and are ongoing attacks in the wild. It is not safe.

Even if only temporarily, please move to another browser.

update: more on this from BBC

What we have now

Over the last several years, I've learned to appreciate good message logging. Mozilla's NSPR Logging API is a very good example, and works well, for compiled code.

JavaScript components? They can't use NSPR. Neither can chrome, PyXPCOM, or any other privileged code. The best alternative I've got is a dump() statement. dump() writes to the standard error console, commonly known as "stderr". In debug builds, though, stderr gets populated with a bunch of other stuff that I really don't care about at a particular moment. (I'm not entirely clear of blame, either - leftover dump statements from my code pollute that console as much as anything else.)

At Skyfire, I've had to implement a couple logging systems as well, and the generated logs have helped us find and isolate bugs relatively quickly. What you log can help you identify bugs in most cases. They're not a panacea, though: doing it wrong can really cost you.

Over the past few days, I hit a really weird bug in Verbosio's templates system (which I've been quietly working on for about five months now, in a complete rewrite with tests). One test fails at a critical point, but it's pretty far removed from the starting point. Amid all the other dump() statements and debug output, I can't quite figure out where the code started going wrong. To pin it down, I think the best approach is to insert some logging.

Oh, and did I mention that Mochitest includes logging for pass, fail, and todo conditions... but conveniently left out an informational-only logging feature? (Having that helps when you're trying to trace where a log statement came from - and the conditions at the time.)

The five paragraphs above combine to form one idea: Maybe I should implement my own logging service with tests.

Thoughts in the design

• First of all, keep it really simple. Most logging implementations I've seen use a module name, a severity level, and a summary string. I figure that plus an optional details string should cover most messages.
• For where those messages go, files are good. Streams are better. With a stream, you can feed it into a file, or read it into dump(), a XUL page's multiline textbox, or anywhere else.
• Someone reading the logs probably wants a way of separating messages - so if I give them a "multipart" stream, where each part is a separate stream... it's easy to tell each message apart.
• Make sure the user requesting the logging stream can specify which messages they want to receive - both by module name and severity level, and whether or not they want the details with each message.
• Make sure to cache all the messages, so that a logging stream created later still gets all the messages that came before it.
• Finally, since each message ultimately ends up as a simple string - use a simple string stream interface to construct each message as needed.

Did I overdo the design? Probably. On the other hand, it really maximizes flexibility. I don't know how much memory multipart input streams consume, though, so I don't recommend using this in a production environment. If you use this logging service for debugging, make sure you remove all references to it before checking in!

Did it solve my problem?

No.

Oh, the logging itself worked beautifully. But to get some of the data I wanted to log, I had to call other functions. Some of those functions triggered JavaScript garbage collection, which tried to run some cleanup code, which tried to execute JavaScript code I wrote, which resulted in a 100% reproducible crash. I don't yet know what I'm going to do about that. I'll probably first try to reduce the testcase and post it.

Also, logging itself will never solve the problem you've got. All it will do is provide data, and hints about where you are in the code execution. You still have to tell it what and when to log, and you have to read those logs to find the bug.

The good news is, though, that a logging infrastructure like this only took one afternoon to write. Sometimes, that's all I need: a quick, simple component to organize the dirty work into one place.

(The code I wrote I am making available under MPL 1.1 / LGPL 3 / GPL 3 tri-license. If you want it under another license, feel free to e-mail me, and I'll almost certainly say yes. I don't currently plan on submitting this in a bug for landing in mozilla-central, though.)

Better to have tried and failed than not to have tried at all, right?

Generations of fathers would say to their kids "of course". But it seems not in every case.

A while back, Mozilla and Debian had several goes at coming to an agreement for the use of the Firefox name and logo. In then end, we collectively failed[0], which is something I consider a great shame. Sadly, this failure seems to have left a significant number of free software people with a residual unhappiness and antipathy towards Mozilla. Which is, in some ways, an even bigger failure.

On the other hand, no-one seems to have even suggested that there's a possibility that the new kid on the block will allow their name to be used when Debian packages their software. So Debian are happily and peacefully packaging it under the alternative name. I haven't noticed anyone being upset about this.

Why is that?

[0] And I'm not interested in reopening the debate about who was right. That's not the point of this post.

I was just invited by a 'friend' to join a Facebook "free laptop" group whose real aim is to get you to take surveys.

Facebook have obviously decided not to have a "Select All" button on your list of friends when you share stuff, to try and reduce spamming. Here's this group's way around that, from their instructions:

3) After that, Click the 'Invite People to Join' link on the left hand side of the page. (Must do it, it's part of how we can give these buttons away for free!)

4) Erase everything in your address bar... (The address bar is where http://www.facebook.com is typed, where you type in a website to go to.)

Then copy and paste the following code in there and hit ENTER.

javascript:elms=document.getElementById('friends').getElementsByTagName('li');for(var fid in elms){if(typeof elms[fid] === 'object'){fs.click(elms[fid]);}}

5) Once you've done that, all of your friends in the box should turn BLUE, Click 'Send Invitations'

So, how about a JS URL which creates form elements mimicing a Facebook login form, waits for them to autofill, and then posts the contents off to a server? (Or did we fix that?) Or one which inserts a <script> tag with a src at an attack site? If people get used to blindly following instructions like this, no good will come of it...

HTML5 <video> with Ogg Theora codec support seems to be pretty popular among those voting on YouTube feature ideas.

These kinds of voting systems are of course heavily influenced by activist types, but it's still nice to see how dominant this feature request is given all of the other solid ideas in the list.

The prolific Simon Willison and a happy band of hackers squirrelled themselves away in a fort in October 2008 and built WildlifeNearYou.com. (MySociety site-naming style, perhaps because Matthew Somerville was one of the hackers involved.)

This means I can now point you at a list of places in the world you can go to see a Firefox (a.k.a. the red panda)!

If you know of Red Panda locations not on that list, you need to upload a photo of it to Flickr and follow the instructions in the FAQ. I'm off to add the one in Symbio Wildlife Gardens, Sydney, Australia.

A few days ago I mentioned that I've been experimenting with distcc. I finally took the time to do some timings. All times below, unless stated otherwise, are for a completely clean debug non-libxul build on my Mac. In particular, none of the files are in ccache, but ccache _is_ being used (so the compile time includes the cost of caching the new object files). distcc is being invoked via CCACHE_PREFIX. The distcc builds were done with -j10 (I also tried higher -j numbers and saw things between no effect and a slowdown as I got up close to -j20) and allowing 10 distcc connections to the server. The non-distcc builds were done with -j3, which is my normal build setup (since the mac in question only has 2 cores). distcc over ssh did not use ssh connection sharing, and was doing X forwarding on each ssh connection; I should retest with those two things changed at some point, if I decide I don't like doing things over tcp. The network is a wireless 802.11g on the Mac laptop end and gigabit ethernet to the wireless router on the Linux desktop. I found that ,lzo for the distcc builds didn't materially affect things (may have made the build 1-2% faster when used).

This was obviously distressing. I didn't test distcc over ssh after this, but particularly distressing was the fact that the compilation seemed largely diskbound and therefore distcc didn't help much. This got me started looking into hard drive performance as a function of utilization, since I could swear that the Mac's hard drive has been getting slower as it fills up. Turns out, this is actually the case. So I moved my rarely-used Linux VM to an external hard drive, which took free space on my internal disk from 4GB to 65GB or so. With that change done:

Progress! Next, I tried dropping ccache, which let me measure the impact of pump mode. Since I do generally see a benefit from ccache, and wanted to measure it, I also tried a build without distcc but with a primed ccache (so build a tree, delete the objdir, rebuild that tree). Results:

So if I were pretty sure I'd almost always be near this Linux box, just not using ccache and using pump mode might be the way to go. As it is, using distcc + ccache seems like a good approach for now.

Now all I need is a way to figure out a way to get this sort of data without it taking several hours, a way to pick good values for -j, and a faster internal hard drive in this laptop.

As part of Mozilla's ongoing stability and security update process, SeaMonkey 2.0.2 is now available for Windows, Mac, and Linux as a free download from www.seamonkey-project.org.

We strongly recommend that all SeaMonkey and old suite users upgrade to this latest release. If you already have SeaMonkey 2.0, you will receive an automated update notification within 24 to 48 hours. This update can also be applied manually by selecting "Check for Updates..." from the Help menu.

For a list of changes and more information, please review the SeaMonkey 2.0.2 Release Notes.

Note: All SeaMonkey 1.x and old Mozilla or Netscape suite users are encouraged to upgrade to SeaMonkey 2.0.x by downloading it from www.seamonkey-project.org.

If you have Mozilla commit access, and your username corresponds to an email address which no longer works, you will have missed important emails about signing the new Mozilla Committer's Agreement. This means

your commit access may go away at any time

(don't make me turn on 'blink') which would be bad. If this is you, contact me, and then follow these instructions, remembering to note on your submitted form the username of your account. And perhaps also file a bug on IT on updating your username.

In case you don't read newsgroups, here's some of Mike Beltzner's latest comment:

The JetPack project is very interesting to Firefox, and we are participating (as should all of you, as interested consumers and stakeholders!) in its development both in terms of building the platform and setting requirements on that platform. It is a stated goal of the Firefox team to do what we can to make it easy to install, uninstall and manage JetPacks alongside other customizations such as Add-Ons, Plugins, Search Providers, Themes, and Personas.

We also plan on continuing to dedicate time to working with the JetPack drivers to help them shake out requirements based on existing Add-Ons and what we know the most common compatibility "gotchas" are. It's my sincere hope that mconnor's "call to arms" will be heeded and that everyone contributes to that effort. JetPack is being built specifically for the purpose of making it easier to write customizations for Firefox, so please, tell us what you find difficult and help us understand what your requirements are.

Many people have interpreted mconnor's post to mean that the Firefox product team has already made a strategic decision to remove support for the existing extensibility platform and technology in the near future: this is not the case. What mconnor wrote was that from a strategic perspective, we will be focusing on building an effective and viable alternative platform in conjunction with our extension development community in order to address specific limitations of the current system. I do not see this as a zero sum game, although as a separate but related issue, some specific aspects of the current model may need to be modified for security and performance reasons (I'm referring to binary components, which will likely need to migrate to js-ctypes.)

I hope this clarifies things, somewhat.

And BZ chimes in as well:

I think this hasn't been made clear enough, actually, so here's my attempt to make it clearer.

Right now we seem to have on the order of 10000 (a bit over 11k if I add my numbers right, but it's the order of magnitude that counts) Firefox add-ons on AMO.

Some of these are actively maintained; some are not.

The really popular add-ons, in my experience, have a tendency to be actively maintained. Even on trunk, adblock+ usually works just fine, and more importantly says so in its version metadata. Same for Firebug (it's been worse in the past, but is getting better). That sort of thing.

However there is a very long tail of add-ons that are not as actively maintained. This is fine; people are doing many of these in their spare time, and even the time they take to bump the maxVersion every time we do a new release is much appreciated. But the net effect is that:

1) Possible beta testers tend to avoid trunk builds because their
favorite add-on or three doesn't work with them yet, so we lose
useful feedback. The version check override approach helps some,
but only if the version check is really the only thing preventing
the add-on from working.
2) Doing a release involves getting several thousand people to update
things on AMO (at least the maxVersion, but in many cases more than
that).
3) Since even the updates from step 2 are not enough for the whole
long tail, we end up with users who are running outdated (hence
insecure!) versions of the browser because their favorite add-on
hasn't been updated.

If we can get to a point where we serve, say, 98% of these add-ons with a stable API that doesn't involve any more changes, and if the most popular of the remaining 2% are updated expeditiously anyway, we suddenly find ourselves with a _much_ shorter tail, and the three issues above become much smaller problems. Note that this doesn't involve all extensions using the stable API, nor does it involve preventing truly innovative extensions from being written, nor anything along those lines. It just involves a preponderance of extensions using the stable API. Note that the stable API can have things added to it as needed; this would probably happen based on feedback from extension developers, especially those who are in fact exploring the space of what can be done with things outside the existing stable API.

I think the above list of problems we're trying to solve, and why Jetpack or some other stable API with growing surface area would help us solve them, is so much in the hindbrain of the people who've been banging their heads on this problem that it's easy to forget that none of the above is obvious "from the outside"....

To be clear, the stable API doesn't have to be Jetpack. Jetpack is the current attempt at creating such a thing, as I understand it.