">
">Version 0.3 of the Bugzilla REST API has been released. New in this version:

• name=value search for arbitrary fields; e.g "&cf;_mycustomfield=somevalue"
• All timestamps are now in UTC, ISO 8601 format
• Support for OPTIONS
• Access-Control-Allow-Origin header now on all responses (permits cross-site requests)
• Support for downloading bug data for multiple bugs, in full, in a single request (see docs for search to find out how)
• Text searches now default to "contains_all" (as substrings, space-sep)
• Initial support for decent error codes - however, don't rely on them not changing!

Compatibility Notes:

• Note that the timestamps format change is backwardly-incompatible.
• All API capabilities now work against bugzilla.mozilla.org, now that it's been upgraded and patched.
• An advance warning: in the next release, the Configuration object's "groups" hash will change to be keyed by ID rather than name (and so also the "id" field will disappear to be replaced by a "name" field).

">
">File bugs |
">
">Feedback and discussion.

There you have it. Before and after.

Just a heads up -- I'll be using bsmedberg's Status Board to push updates about the Android porting work; as other people get involved, you should see their updates there as well.

I purchased a Droid when they came out.  It's my first Android device, and it's been an interesting experience.  I am not a fan of the iPhone, and I've been using a Blackberry for the past few years (an 8700 first, then the original Curve, then the updated 8900).   The Droid is a great looking device; I like the industrial look, with my only complaint being that the big gold-coloured area on the D-pad is way too garish; it would also have been nice had that area been a trackpad-like virtual trackball.  The keyboard leaves a lot to be desired, though.  It's a physical keyboard, which is nice, but it's no match for a Blackberry keyboard.  Typing on it is slow and cumbersome, given the very wide layout, and some keys are very oddly placed.  (I found it amusing that while the Blackberry has a dedicated unshifted key for "$", the Droid has a dedicated key for "?"...)

The feel of the OS is pretty nice, although some things are more sluggish than they really should be on an OMAP3 device.  Stuart keeps telling me that Fennec has smoother panning in the browser, and I think he's right.  It's not a deal breaker though; I find myself using the browser a lot to do all sorts of things that I never would have considered on my Blackberry (because, wow, the web browser situation there is awful), but that was a frustrating experience on my iPod Touch as well.  I've spent a while "browsing the web" on my phone, which I've never been able to say I've done before.

But, it's still a phone, and while the voice portion isn't all that important to me, the overall communication package is.  Coming from a Blackberry, the overall messaging situation on the Droid is simply horrible.  Email, whether Exchange or IMAP, is a disaster.  The email client seems designed for simple "lol r u there" type of messages, and even the message lists don't seem intended for people who get more than 5 messages a day -- turning a message list into landscape mode is worthless as you only get to see about 3-4 messages in the list (same view as in portrait mode, just along the much smaller axis of the display), no IMAP IDLE support etc. are all very strange on a top-end phone.  Exchange support works ok for Calendar sync, but for email sync it would only download the first 1000 bytes or so of a message, including headers; this meant that I often only got to see the first sentence or two of an email.  I don't know whether this is a problem with the Droid or our Zimbra Exchange connector, but switching to IMAP for work mail fixed that problem.

An recently-released version of the open-source K9 Email Client that works on the Droid resolves many of these issues, though it needs some polish.  I might write some code there, since it's close to becoming a pretty good email solution.

The Gtalk client is probably in worse shape than email.  It's almost as if Google entirely ignored Gtalk on this device (and I can't believe that would be Verizon's fault, since things like Google Voice work just fine).  First, it's in general buggy -- it's crashed on me multiple times, often freezes when returning to it from another app (after clicking a link to the browser, for example), and often shows contacts as offline with a big red message despite the contact clearly having a green dot next to their name and responding to my messages.

In the browser and in other apps, you can share a web page with someone using a "Share with" button.  The list you're presented is conspicuously missing Gtalk, despite having Facebook, Email, Messaging (SMS) and a random Twitter client I installed on there.  What gives?  All of these features are available on the Blackberry; I'm not sure if it was RIM that did the Gtalk app there, but can we get whoever it was to rewrite the Android one?

One of the best things about the Blackberry is the unified messaging; there's a single view where I can go to see all my emails, my gtalk conversations, my SMS messages, app updates, and whatever else.  No such thing exists on Android.  The closest thing is the notification bar, which requires a swipe down to use, and then only shows things that have come in since the last time you looked.  I'd prefer a more time-based list that contains both old and unread items.  Sounds like the Sony-Ericsson X10 might be doing some interesting things there, and I hope that someone figures out how to create an app like this.  What it comes down to is that anything to do with communication is faster and simpler on my Blackberry, which is really strange; you'd think Google would have spent some time working this out, as everything else about the device is far superior to my 8900.  I understand that more "enterprise oriented" customers (which apparently means those that like to use email a lot?) aren't necessarily the target market here, but they could've really attacked that market with some simple work that wouldn't have affected anything else.

The good news is that all of these are fairly straightforward software issues.  The hardware is solid, and Google has shown that they'll do frequent upgrades of the OS.  Given that the Droid is a "Google Experience" device, those updates should find their way to the device quickly.  Some fixes, combined with getting Firefox Mobile on the Droid and other Android devices, will make this a great phone.

The grand beard experiment of 2009 comes to an end tonight. Here's one last look.

Currently, Mozilla has a large number of code trees in various source code management systems, many of which have differing requirements for access. This is confusing and difficult for both developers and administrators. This document is the first draft of a vision for what a unified commit access policy might look like. Having a clear commit access policy makes the lives of developers and administrators alike easier. ...

This new unified Commit Policy is likely to need careful review and improvement; I've been working on this for a while now but I'm still sure I haven't got it right first time. Comments welcome in mozilla.governance.

Firefox is rocking central and eastern Europe.

I've been looking to understand the Android OS better, so that I can answer some questions and create plans for getting Gecko/Firefox running on Android-based devices.  One of the first questions I asked was, "How do Android apps start?"  They're clearly separate processes while they're running, but it wasn't clear how they were launched.  It turns out, there are a couple of pieces here.  I'm going to describe what I've discovered here, in case it's useful for someone else; I haven't been able to find much of this information, largely because I don't think many people need to know any of this.

At boot time, a special instance of the Java VM is launched, called the Zygote.  This process loads a bunch of the core Java classes and performs initial processing of them, making it possible to avoid this step for each app launch.  Once the initial work is done, the process listens to a socket and waits for requests.

To launch an app using the Zygote process, a command-line tool called "dvz" can be used.  It sends its arguments to the Zygote, which will fork and then start executing the main method in a given class.

So, we have these steps, dealing with the Zygote process:

• the zygote process is executed at system boot; it does initialization, and then runs a select() loop listening to requests
• the zygote process is sent a message, which includes the start args, which will include the class name for main launch
• the zygote process reads connection args in ZygoteConnection.runOnce
• the zygote process forks in ZygoteConnection.runOnce (Zygote.forkAndSpecialize, native)
• ZygoteConnection.handleChildProc is called, which does some cleanup and eventually throws a MethodAndArgsCaller (via ZygoteInit.invokeStaticMain)
• ... which takes us all the way back to ZygoteInit.main, which catches that trampoline exception, and calls run()

But, that's not fully how a new Android Activity is started.  It's a bit of a roundabout process.  To launch a new Activity, the ActivityManagerService is notified with an activity start request, including things like the name/class/etc. of the activity.  It puts that information in a list of activities to run.  Then, a new process is started with the main from ActivityThread.  This new process then contacts the ActivityManagerService and asks, essentially, "what app am I?".  The service then gives it the name of its activity class and other info, which is then loaded, and a message is enqeued on the main thread to instantiate the new activity and send it an onCreate() message.

This is interesting because it means that apps are not launched directly, but instead somewhat indirectly through specializing a generic "Activity" process for a specific activity.  A side effect of this is that I couldn't find a way to actually register an app with the ActivityManagerService if it wasn't launched by it.  So, to be a full Android app, you have to go through this normal startup process.

JNI Bridging

One of the difficulties in porting Gecko to Android is that the Android platform is built around Java, whereas Gecko is very much all native C/C++.  However, there is a fairly good native bridge layer, JNI, which is fairly heavily optimized by Dalvik.  So, the simplest way to connect these two is to write a shell app in Java, which bridges events, messages, paint requests, etc. to the native code for handling.

As a proof of concept of this, I wrote a simple test app.  It's fairly straightforward, with a few wrinkles.  Most of this stuff can be done with the stock Android SDK and NDK -- except painting.  The only API that the NDK exposes for graphics is OpenGL ES.  This is fine, but in some cases you may want to access Skia directly from native code.  This is possible, but requires version-specific code to accomplish.  You can ship multiple versions of your JNI glue layer, optimized for each Android version (or even platform), and load the right one during your app startup on the Java side.

This is, of course, not very portable, robust, or guaranteed to continue to work by Google, but it's possible.  There are some very rough hacks in the test app, but for the most part it demonstrates that this approach can work fine.

Next up, I'll probably blog about porting issues for large native apps, including library compatibility, Bionic, and integrating into a non-ant-based build system.

The Mozilla project continues to kick ass and Mitchell's state of Mozilla report describes much of that ass kicking.

Check it out.

There's a rumor out that Sony is looking into bringing Firefox to the PS3 platform:

"We recently received a tip from a source very close to Sony who says that they have been in talks with Mozilla lately about possibly porting firefox over to the PS3. That said, our source made sure to point out that they were unsure if any deal had actually been reached at this point, but it is great news none the less considering the complaints Sony has been getting about the lack of reliability with their current built in PS3 web browser."

Read more

At some point, for some reason I cannot quite fathom, a WordPress or PHP or mySQL or some other upgrade took all of my WordPress database’s UTF-8 and translated it to (I believe) ISO-8859-1 and then dumped the result back right back into the database. So “Emil Björklund” became “Emil Björklund”. (If those looked the same to you, then I see “Börklund” for the second one, and you should tell me which browser and OS you’re using in the comments.) This happened all throughout the WordPress database, including to commonly-used characters like ’smart’ quotes, both single and double; em and en dashes; ellipses; and so on. It also apparently happened in all the DB fields, so not only were posts and comments affected, but commenters’ names as well (for example).

And I’m pretty sure this isn’t just a case of the correct characters lurking in the DB and being downsampled on their way to me, as I have WordPress configured to use UTF-8, the site’s head contains a meta that declares UTF-8, and a peek at the HTTP response headers shows that I’m serving UTF-8. Of course, I’m not really expert at this, so it’s possible that I’ve misunderstood or misinterpreted, well, just about anything. To be honest, I find it deeply objectionable that this kind of stuff is still a problem here on the eve of 2010, and in general, enduring the effluvia of erroneous encoding makes my temples throb in a distinctly unhealthy fashion.

Anyway. Moving on.

I found a search-and-replace plugin—ironically enough, one written by a person whose name contains a character that would currently be corrupted in my database—that lets me fix the errors I know about, one at a time. But it’s a sure bet there are going to be tons of these things littered all over the place and I’m not likely to find them all, let alone be able to fix them all by hand, one find-and-replace at a time.

What I need is a WordPress plugin or something that will find the erroneous character strings in various fields and turn them back into good old UTF-8. Failing that, I need a good table that shows the ISO-8859-1 equivalents of as many UTF-8 characters as possible, or else a way to generate that table for myself. With that table in hand, I at least have a chance of writing a plugin to go through and undo the mess. I might even have it monitor the DB to see if it happens again, and give me a big “Clean up!” button if it does.

So: anyone got some pointers they could share, information that might help, even code that might make the whole thing go away?

I just spent the last two hours or so trying to get wake-on-lan to actually work on Linux. Sadly, most of the HOWTOs (assuming the link isn't broken) aren't actually that useful. Here's what I can observe

1. Wake-on-LAN is enabled in the BIOS.
2. Shutting down with "poweroff" or "shutdown -h" leaves the network card powered (the link light is on).
3. Sending a magic packet to the machine doesn't power it on.
4. If I hit the small black button on the back of the power supply once, it makes a slight noise, and after that sending a magic packet does power on the machine.

So my best guess so far is that poweroff puts the power supply into a state from which the NIC can't wake it up. I have no idea what that state might be, nor how to change this behavior. I welcome any ideas!

Update: To be clear, I've tried all the power management setting combinations in the BIOS. Most have the behavior I describe above; the rest power down the network card as well.

Update: To forestall more comments from people who aren't reading item 4 above carefully, the network card itself reports that it'll do wake on magic packet when you ask with ethtool. It DOES do wake on magic packet, in fact, but only after I press that button on the power supply. And honestly, try to give me some credit for actually trying the one thing all the howtos on this have in common, that being ethtool.

NeoWin is reporting that Microsoft will be revealing their Internet Explorer 9 plans tomorrow at PDC.

Here are my predictions:

Microsoft will demo an early build of IE 9 that will feature an all new and super-fast JavaScript engine. They will show an updated Office Web that utilizes JS threading, <canvas>, HTML5 drag and drop events, online and offline events, some kind of local storage, lots of CSS3, including some CSS 3 text and font additions, columns, and maybe some box styling additions.

They will commit to supporting most of HTML5, including adding at least preliminary support for <audio> and <video> tags, local storage, drag and drop, and they'll commit to most of CSS3 but not all of it in time for the IE 9 release

They will also talk about or demo some other awesome capabilities that won't get nearly the press coverage as those items listed above. I expect to hear something about ICC color profiles, and possibly even some cool device DOM APIs like geolocation and orientation.

I predict that we'll all be shocked and that the IE 9 plan will signal that Microsoft is committed to to joining the modern browsers in moving the Web forward.

Microsoft dug a huge hole when it mostly abandoned IE 6 and the Web from 2001 until 2006. Their early efforts at ramping back up with IE 7 were a big disappointment to most Web developers and while their efforts with IE 8 were much better, they're still at least a full generation behind the modern browsers.

That team has some really strong people and they're not going to let another release go by where they're still seen as badly trailing. Not with Office moving to the Web. Not with Search and other web services becoming huge revenue opportunities.

Falling short with IE 9 would be the last straw for Web developers' little remaining faith in Microsoft and so they won't miss this opportunity.

That's my prediction. What do you all think?

update: Bummer, Ina's reporting that we're not going to see IE 9 at PDC.

update: Looks like I got some of this right. Let's all hope that the rest comes to pass as they move further into the development of this next version. When any browser improves, the Web improves. It looks to me like Microsoft is getting more serious about improving the Web. This is good news and the IE team should be hearing our positive feedback and encouragement.

If you're an add-on developer, it would be good to read this post. Firefox is going to make some huge improvements to Firefox's stability and your extension might be affected.

Over at Cnet's Crave, Flora Graham's written up a great mobile browser comparison article. The take-away for me? Firefox Mobile is coming on strong.

Of the six browsers they reviewed, Skyfire , Opera Mobile, Firefox Mobile, Safari, Mobile IE, and
BlackBerry browser, the still in beta Firefox Mobile came in second place.

Here's what Flora had to say about Firefox Mobile.

Fennec was insanely fast at loading complicated pages -- the fastest of the browsers we tested. But there's no Flash support yet, and we had no trouble crashing this prototype version. Nevertheless, it may be worth a few crashes to take advantage of Fennec's slick user interface, speed and support for loading multiple simultaneous pages.

Stability and Flash support are obviously things we have to improve for the final release, but to have our first mobile product coming out of the gates with superior speed and UI speaks volumes.

The mobile browsing market isn't locked up, no matter what some of the other guys might think.

It's a bit last minute, but the Firefox 5th Birthday Party in London will be happening this Thursday in collaboration with OpenSoho at their monthly event. It's at the Hub Culture Pavilion, a collaborative workspace at 49 Carnaby Street, Soho (map) from 6.30pm onwards.

The cost is normally £5, but you can use the discount code "mozillavip" to sign up for free - there are 50 places available for Firefox fans. William is coming over from Paris to join us; hope to see you there too :-) If you are a London-based geek, please feel free to publicise this to other Firefox fans via your blog, Twitter or whatever.

I find myself in the market for two things, and was wondering whether anyone has any recommendations:

1. Luggage. I'm looking for something to check (not a carry-on) for trips when I need to take a bunch of stuff along. Obvious desirable qualities are being sturdy enough to deal with being checked, spacious, light. Bonus points for noticeable (e.g. brightly colored), cheap. Given how I use luggage (e.g on hilly sidewalks), I'd want one of the ones with 2 wheels, not 4 wheels.
2. Digital camera. Just looking for a point-and-shoot. Main criterion here is that it have good enough quality to print, not just look at on screen. I suspect any modern camera will have most of the rest of what I want (reasonable capacity, decent battery life, ability to shoot close-ups if needed). If I can find something that doesn't have a delay on the order of 1s between me pushing the button and the picture being taken, that's a big plus! Past that, I'm not even quite sure what typically differentiates digital cameras nowadays; haven't shopped for one in a while.

I welcome any advice people may have.

Status 2009-11-13. Highlight: finally managed to release REST API 0.2! Although it only works fully against bugzilla-stage-tip.mozilla.org at the moment, it will work on bugzilla.mozilla.org after the upgrade, which is now scheduled for this Sunday. But this is good enough for people to test things on a relevant bug non-critical data set.

A new Postbox BETA release is now available for testing. Here’s what’s new:

• Languages - To use a different language in Postbox, go to File / Languages and select a language. Note: translations may contain some English strings since they are still being worked on by volunteers.
• Incorporated Mozilla Firefox 3.5.5 security and bug fixes.
• XLIST support for IMAP servers, which enables Postbox to automatically detect special folders such as Sent, Trash, and Drafts in accounts such as Gmail.
• Account Setup - When creating a new mail account, Postbox will attempt to figure out your connection settings for you.

Note: This beta is intended for early evaluation and feedback, and users of the latest released version of Postbox should not expect all of their add-ons to work properly with this beta.

Download the Postbox 1.1 BETA 2 Release

• Windows
• Mac OS X

Submit Feedback

We’re excited to hear your feedback on Postbox 1.1, so please use our beta site to report issues or ask questions about this release.

Special Thanks

This beta includes several enhancements from the Mozilla platform. A special thanks to the entire Mozilla community for continuing to move the platform forward.

- The Postbox Team

It has become important in recent years for web browsers to know something about the de facto 'shape' of the DNS - e.g. to tell the difference between co.com (someone's domain) and co.uk (a registry-specified suffix under which people register domains). This is used to stop cookie leakage between domains, to highlight the important parts of a domain name, and for other things too.

To do this, Mozilla started the Public Suffix List project, a cross-browser initiative which tries to maintain such a map. This list is used by Opera and Chrome/Chromium. Thanks to some heavy lifting at the start of the project by some very hard-working volunteers, the list is pretty comprehensive (although we tweak it regularly).

IE 8 also needs to know this type of information, to power things like its domain highlighting in the URL bar. The excellent Eric Lawrence's post on the IE blog details what they use it for and how their code works. You can see there the algorithm that IE used in all versions prior to IE 8.

In IE 8, they made changes to improve the accuracy of the algorithm. Sadly, although the licensing on the data is designed to enable them to, they have chosen not to switch to using the Public Suffix List. Instead, they have kept their old heuristic but added a set of exceptions - ietldlist.xml, which is bundled with IE 8. (If you have IE 8, you can see it by visiting the URL res://urlmon.dll/ietldlist.xml).

This is sad a) because it makes the browsers inconsistent with one another and b) because IMO their algorithm and list combination does not produce results as good as the Public Suffix List. Here are some issues:

• The IE list contains typos (I'm fairly sure about most of these):
  • aeroport.ci (aéroport.ci)
  • ciesqyn.pl (cieszyn.pl)
  • golgow.pl (glogow.pl)
  • udmautia.ru (udmurtia.ru)
  • prindipe.st (principe.st)
  • edunte.tn (edunet.tn)
  • cherrnigov.ua (chernigov.ua)
• The .aero, .pro and .museum gTLDs have a large number of reserved subdomains; these aren't recognised.
• There is likewise no attempt to deal with the subdivided complexities of Italy (.it), Japan (.jp) and Norway (.no).

That's not to say we don't have things to look into either; I've filed a bug to follow up the places where IE has an entry that we don't.

I've written a Perl script implementing both algorithms (PSL courtesy of the regdom-libs project) so people can see the differences for a particular domain. Note that I can't redistribute ietldlist.xml, so you'll need to obtain your own copy of that before the script will run.

I hope Microsoft will consider using the PSL for the next release of IE, so we gain cross-browser consistency and can all work together to maintain a single map of the DNS. We are happy to work with them to make that possible.

It wasn’t what I would call unseasonably cold, but then the season was mid-autumn and the afternoon wind along the river did cut the skin a bit. I kept my leather jacket zipped up all the way as I made my way back to the hotel with shopping bag in hand. Brisk, I might have said back home, or even chilly. Not winter yet, but you could feel it coming in the snap and shift of the air.

I crossed the last street before the hotel, keeping an eye on both the short-cycle light and the short-tempered traffic. Not that there was any particular reason for them to be short-tempered—it was a Sunday afternoon and there were hardly any cars on the bridges and roads that grid the downtown area—but I knew from experience that pedestrian intimidation was something of a sport for the locals, and I really didn’t feel like tempting fate, or at least somebody’s ideas about what constituted a bit of fun.

Having threaded through the small bunch of oncoming pedestrians and reached the relative safety of the sidewalk, I came upon a large man with two children in tow, all bundled against the cold in parkas and scarves and hats. He asked if I had a minute, and I immediately knew what was coming. Sure enough, it came out: the request for a dollar, some change, anything I could spare. I glanced at him, at the children, back at him. Something for bus fare, he said. They’d missed dinner at the Mission the night before, he said. Just a little help, anything I could do, he said.

How many times had I heard this before? I gave the usual excuses about not having any cash, I only travel with credit cards, so sorry, had to go.

And went, the wind biting into my cheeks as I strode to the hotel’s front door, the overhead heater blowing a curtain of warmth across the entryway. Into the lobby. Into the elevator. Thirty floors into the air. And in my sight, still, the children looking at me. The boy of maybe eight, looking up at me curiously. The girl of six, peeping at me warily from behind the man’s bulk. Props? Accomplices?

Did it matter?

I stood at the counter of the lobby gift shop, stacks of nutrition bars in my hands. A bottle of water in the side pocket of the jacket I had yet to shed. An apple in the other. My credit card between two fingers, ready for the attendant to take.

Through the doors, into the cold wind under the canopy, the plastic shopping bag weighing down my hand. I reached the sidewalk and there they were on the same corner, looking like they were getting ready to cross the street. I caught the man’s eye, signaled him to wait. As I approached his face shifted, softened, something like relief warring with shame melding into a curiously childlike expression.

“God bless you,” he said to me, and I chose to believe that he meant it. The little boy smiled up at me, a tiny edge embedded in the corners of his mouth. The girl still peeped warily, maybe even more so now. The man and I were shaking hands, looking squarely at each other for a moment. I told him to make sure to get the kids to that Mission dinner. I could think of nothing else to say, because it was the only thing I was thinking. Get the kids fed, keep them as healthy as possible, no matter what else.

As I turned into the recessed, canopied area that sheltered the hotel’s front door, I glanced back at the street corner. The three of them were waiting to cross toward the small park to the north, the gift shop’s white bag ludicrously small in the big man’s hands, and then they were occluded by the building’s corner. I walked back through the wall of warm air, into the dim lobby and out of the bright outdoors, thinking that there was every chance I’d been suckered, and knowing that it didn’t matter.

The world stands on its head

As announced, the Xoopit for Gmail service will be closing down this Friday, November 13th, 2009. If you’re currently using Xoopit, your files and photos will still be attached to your Gmail messages, but you will no longer be able to access Xoopit services.

To receive a similar experience, you could migrate all of your email to Yahoo Mail, but there’s another compelling alternative — Postbox!

Postbox gives you instant access to files and photos buried within your email messages.

You can search for files and photos by contact, subject, date, text snippet, or tag from almost anywhere within the interface. Postbox then provides you with simple and intuitive ways to use what you’ve found.

Postbox works great with Gmail, but it also works with files and photos from ALL of your email accounts, including Yahoo mail, your work mail, or any other POP or IMAP account.

And because Postbox does all of its cataloging on your computer, you won’t have to surrender your email credentials to a third party, or compromise the privacy and confidentiality of your email data.

Postbox is quick to download and a snap to install, so if you’re a Xoopit for Gmail user, or simply want a better way to find and use email content, then we hope you give Postbox a try!

- The Postbox Team

We’re finally at the point where I can say we’re ready to upgrade Bugzilla @ Mozilla this weekend.  We’re aiming for Sunday evening (probably 6pm PST).  I’ll post again when I know how long it’ll be down for (and that’ll be included in the eventual downtime notice on the IT blog as well).

There’s a staging copy set up at https://bugzilla-stage-tip.mozilla.org/ and I would appreciate people playing around with it and finding anything that might be broken before we get it to production.  Before filing bugs, make sure to check the detailed status linked from the red box at the top of every page to make sure it’s not already listed (and you can also see my progress on cosmetic issues and so forth, there).

It will be down for a while at some point tonight when I reload it with an up-to-date snapshot of the production server (and that’ll be my test to find out how long it’ll take to upgrade it, too).  I’m super excited because this has been a long time coming.

Here's a set of screenshots I put together for some reporters doing 5 year articles.

The series goes from Phoenix 0.1, released September 23, 2002 to Firefox 3.6 Beta, released October 30th, 2009.

Version 0.2 of the Bugzilla REST API has been released. New in this version:

• Read/write support for flags, groups, custom fields and comment privacy
• Access to all aspects of Bugzilla's configuration with a new /configuration call
• Even more high-quality and comprehensive documentation
• Better logging so I can debug problems

Note that these new capabilities will not be available on the copy of the API pointed at bugzilla.mozilla.org until the upgrade :-( But in the mean time, you can test them on the staging server. Although that seems very slow at the moment.

I consider this the first version of the API with which you should be able to write a capable Bugzilla client of some sort. Let me know if you find stuff missing which would be required for this usage.

Lastly, there is now a Bugzilla component for you to file bugs in :-)

A little more than eighteen-hundred days ago, I and many others held our breath as the much-anticipated Firefox 1.0 was released to the world. A million downloads in the first week pushed our server infrastructure to the brink, and left me reeling: we had come so far from the days of Netscape 6 and the drive to Mozilla 1.0. Our message of a better browser experience, exemplified by the security and performance and personalization and open source and standards-friendliness of Firefox, had found a welcoming audience.

We faced, then, a daunting series of challenges: shifting focus to our most promising product (Firefox) while maintaining the energy and contribution of the Mozilla community; making the project sustainable over the long term, within the inviolable parameters of our mission; navigating new waters of commercial-non-profit-hybrid-community-mainstream-competitive software. We’ve had success at all of those so far, by my lights, though surely not without our bumps and scrapes.

The world is very different today than it was when Firefox was born. Microsoft has rebuilt its browser team, and released two major updates to its browser — at the time, I counted IE7 as one of Mozilla’s greatest achievements. Two other software Goliaths, Apple and Google, have joined the browser fray with gusto. Where once only Opera dared to tread, the browsing experience is now seen as a defining characteristic of a mobile phone, and we are ourselves getting ready to rock it.

Even in this savagely competitive environment, Firefox and Mozilla continue to thrive. Of our 330 million users world-wide, more than 100M of them are in the last year, and 30M in the last two months alone. We’ve continued to grow incredibly even since the latest competitor entered the scene, because we’ve continued to relentlessly improve Firefox and the web in ways that matter to people around the world. Every day we, along with our incredible and essential mirror partners, ship almost twice as many Firefox downloads as we did in that incredible release explosion from five years ago.

In January, I’ll have been involved in Mozilla for a dozen years. It has been a lot of work and a lot of fun, a professional and personal opportunity that I think makes me one of the luckiest software professionals ever to whine about their debugger. Thank you to everyone who has helped make Firefox what it is today, and what it will be tomorrow. There’s lots more to do, but please take at least a few minutes today to sit back and relish the impact you’ve had on the web, and on the people who use it.

Five years ago, on November 9th, 2004, we set the world on fire with the launch of Firefox 1.0 and the beginning of the modern era for Web browsers.

On that day, I was too exhausted to write a serious blog post about the occasion, but thankfully history has spoken louder than any words then could have.

Today, with somewhere between one quarter and one third of global browser usage, 330 million Firefox users have made a statement that the browser matters. That may sound uncontroversial today, but 5 years ago most people really didn't get it.

But some of you did and you not only made the choice to move to a better browser, but you spread the word to hundreds of millions of others and became the largest grassroots software community the world has ever seen.

There's a lot to celebrate today, but the people of Mozilla -- the thousands of you who made this all happen, you all are what I'm celebrating. Thank you for making such a profound difference in how we all experience the Web. Thank you for improving the lives of hundreds of millions of individual human beings.

WebGL introduces two interesting concepts that I think have application outside of WebGL, the CanvasArrayBuffer and CanvasArray.  This is all subject to change, of course, though this is what the current Gecko (and others') implementation looks like.  In particular, the Canvas prefix in the names might change soon.

It became clear that pure JS arrays are not a useful way of shoveling around lots of 3D data; their very flexibility makes them impractical for performance-critical uses.  In particular, WebGL often wants to deal with arrays of a specific type -- an array of integers, an array of floats, etc.  Even more complicated is the need to manage multiple types within a single memory region; for performance, it's often preferable to allocate one chunk of video memory, and place coordinates, colors, and other types in there, replacing them as necessary.

There are two portions to the solution: the CanvasArrayBuffer and a set of typed CanvasArray views.  A CanvasArrayBuffer represents chunk of data.  It can be allocated with a size in bytes, but it can't be accessed in any way.  To actually manipulate the data inside a CanvasArrayBuffer, a CanvasArray has to be created that references it.  An example:

var buf = new CanvasArrayBuffer(3*4);
var floats = new CanvasFloatArray(buf);
floats[0] = 12.3;
floats[1] = 23.4;
floats[2] = 34.5;

The above chunk of code allocates a 12-byte CanvasArrayBuffer, and then creates a float-typed view onto the buffer which can then be manipulated (almost) like a normal array.  Of course, the above is cumbersome to write, so there are shorthands that will allocate a CanvasArrayBuffer, and optionally fill it with data from a JS array:

var f1 = new CanvasFloatArray(3);
var f2 = new CanvasFloatArray([12.3, 23.4, 34.5]);

The size of each CanvasArrayBuffer is fixed; there is currently no way to change its size once allocated.

Multiple CanvasArrays can reference the same CanvasArrayBuffer.  For example:

var buf = new CanvasArrayBuffer(12*3*4+12*4);
var points = new CanvasFloatArray(buf, 0, 12*3);
var colors = new CanvasUnsignedByteArray(buf, 12*3*4, 12*4);

This creates a buffer of 192 bytes, which is enough room for 12 3-coordinate float points followed by 12 RGBA colors, with each component represented as an unsigned byte.  The arguments to the CanvasArray constructors are the offset from the start of the buffer (in bytes), and the length (in elements).  The offset must always be a multiple of the element size (to preserve alignment), and the buffer must obviously be large enough for the given offset and length.  If length is not given, the length is assumed to be "from offset until the end of the array buffer"; that value must be a multiple of the element size.  If offset is not given, it's assumed to be zero.

For extra complex use cases, CanvasArrays can reference overlapping regions of a CanvasArrayBuffer:

var buf = new CanvasArrayBuffer(192); // same value from above
var points = new CanvasFloatArray(buf);
var colors = new CanvasUnsignedByteArray(buf);
points[0] = 12.3;
points[1] = 23.4;
points[2] = 34.5;
colors[12] = 0xff;
colors[13] = 0xaa;
colors[14] = 0x00;
colors[15] = 0x00;

In the buffer, this writes 3 float values followed by 4 byte values.  You'll note that this use is significantly more complex, and requires the user to keep track of the current position in terms of whatever element they're modifying (thus setting array elements 12, 13, 14, and 15 for the color).

If an attempt is made to store data in a CanvasArray that doesn't fit within the right type, a C-style cast is performed.  If the data is an entirely wrong type (e.g. trying to store a string or an object), Gecko currently throws an exception, but this might become a silent 0 or similar in the future.

Where does this fit in WebGL?  Any API function that needs an array of data takes a CanvasArrayBuffer.  This avoids placing costly JS array type conversion in a potential critical performance path, and simplifies a number of aspects of the API.  So, VBOs, texture data (if not loaded from a DOM image element or from a CanvasImageData object), index array, etc. all use CanvasArrayBuffers/CanvasArrays for pulling data in and out.  CanvasArrays also help manage memory usage -- an array of byte color data now takes up exactly as much memory as needed, instead of getting expanded out to 4 bytes.  Also, critically, floating point data can be stored as 32-bit single-precision floats instead of 64-bit doubles, taking up half as much space when the underlying graphics system can't support 64-bit values.

This API is overall lacking in developer niceties, since the focus was on providing the necessary functionality.  Higher level wrappers can be written in JS to simplify usage.  In addition, by keeping it as bare-bones as it is, it allows for fast implementation on native hardware via the JITs in all the current-generation JS engines.  The web currently fudges around the problem of binary data by passing it around either in strings (because JS strings are UCS2, therefore all 8-bit elements are valid, but with a performance and memeory cost), or often encoding as base64 (again going back to strings).  I can see this type of dense/native type access being useful for both the File and WebSockets APIs as a way to exchange and deal with binary data.

Just an observation: Firefox and Facebook have pretty much the same number of users.

Gerv Status 2009-11-06.

For those of you waiting for the official release of Bugzilla API 0.2: it's still blocked on getting some small support patches on to bugzilla-stage-tip.mozilla.org or bugzilla.mozilla.org. Despite my begging and pleading, it's looking like this won't happen until the upgrade to Bugzilla 3.4, which keeps getting postponed :-(

Someone added a comment to a previous blog post about this, but I think it deserves some wider publicity - particularly as I commented on the need for this sort of thing in mpt's usability talk at LUGRadio Live.

Pongo is a poor man's usability lab - it records the screen, the mic and the webcam and wraps them all up into an Ogg file for review. Here's the original blog post from the author (the original was in Python, but it got ported to C).

If there are usability people who could pick this up and take it a bit further, e.g. to the stage of being packaged for Debian and Ubuntu, that would be amazing.

It's Wednesday, and with that, time for another post in the ongoing series of SeaMonkey 2 contributor intereviews! This time, we'll continue with a guy who's known on IRC as InvisibleSmiley:

Who are you?

I'm Jens Hatlak, German/Austrian, single, located in Frankfurt, Germany, and still on the better side of 30. :-) I've been working as a PHP web developer for a large logistics company since I left university (computer science, TU Darmstadt) in 2007.

I chose my nickname, InvisibleSmiley, because I think it's funny to tell people that's what they missed when someone made a statement with hidden irony. ;-)

I like to play the piano, although I'm not especially good at it. I'm a good swimmer, though, a science fiction fan, and a grammar guru (avoiding the more popular alternative term here for hopefully obvious reasons).

How did you become a SeaMonkey contributor?

I started using Mozilla when it was still in the Milestone phase (around 2000), so I was a beta tester almost from the beginning, but only watching the game back then.

In 2001 I made my first Bugzilla comment and filed an enhancement bug (still open!). I also started university that year where I joined a group of system administrators responsible for the computers of the computer science department (some thousand students). After some time I took over the responsibility of not only the web server but also parts of the software installation, including Mozilla (later also Firefox, Thunderbird, and SeaMonkey), all on Sparc/Solaris. During that time I learned how to compile software from source under difficult conditions and how to write patches. However I was still not actively contributing code. Even when I worked on MozPETs I sticked to what I knew (compiling ) instead of diving into extension development and trying to understand the basic principles like XUL.

I kept using SeaMonkey when Mozilla decided to drop the suite, staying on the bleeding edge (nightly builds). When MozillaNews went on hiatus (and with it its Bonsai Watch bug tracker) I started to track SeaMonkey-affecting bugs myself, just out of interest. At some point in time I decided to push the results to a place where I (and others) could find and search them: The SeaMonkey Trunk Tracker was born. I learned how to build SeaMonkey on Windows and updated my public build instructions, but other than that I just watched development progress.

My active participation in SeaMonkey development started only last year, in October 2008 (funnily by posting a patch one minute after another developer submitted almost exactly the same), when the code had already moved to Mercurial. I was surprised by the fact that simple changes and corrections were much easier to accomplish than I had thought, so I continued to contribute small patches. The rest is history . :-)

What notable contribution did you make to SeaMonkey 2.0?

I must have touched almost all parts of the UI by now... Let's see.

• fixing Get All Messages (my only trip to C++ land)


• improving the Cookie Manager (making it searchable, among other things)


• adding the ability to delete bookmarks from search results (and working with Neil to make sure deleted bookmarks do not show up there anymore)


• writing several new or updated Help articles


• adding support for more Firefox-compatible command-line options


• adding UI for the MailNews Archive functionality


• supporting standard key and double click events in the new Download Manager


• adding support for multimedia keyboards to MailNews


• porting the Master Password workaround in time for SeaMonkey 2.0

This may look like much (and it's certainly not few) but it's nothing compared to what people like Neil contributed in the same period of time: just think of all the reviews he made! Respect.

Beyond that I looked into making some popular extensions compatible with SeaMonkey 2, i.e. ones that need more than just a version bump. So far I have been successful with Nostalgy, Flat Bookmark Editing, Download Statusbar, and Firebug (yes, that's right!). I hope the latter can be fixed at the source, the others should appear at the xSidebar site sooner or later.

How can users give something back to you?

I don't know, maybe a bar of good chocolate? :-)

Seriously, my personal needs aside I'd like to see more people getting involved in the project. If you are maintaining an add-on (extension or theme), now would be a fine time to make it SeaMonkey 2.0 compatible. But coding is only part of it, so if you feel like you should give something back, you could help with marketing, quality assurance (e.g. organizing bug days), design (especially icons!), featured articles (e.g. blog posts with screen shots or videos) or even usability considerations. Helping other people in fora and newsgroups is also appreciated, of course. :-)

Oh, and if people would stop mistaking "it's" for "its" that would be nice, it hurts my eyes. :-P

Why, in your eyes, should people use SeaMonkey 2.0?

Because it has everything you need in one place. I think it's the combination of browser and MailNews that I like best but I've learned that people have different reasons for using SeaMonkey, and all of them are valid. I'm not saying that everyone should use SeaMonkey, though; in fact I tell people who really want to use just a browser to use Firefox instead if they feel comfortable with it. In the end it's just a matter of personal preference.

What next step do you see for SeaMonkey, and what would you like to happen in the Mozilla and SeaMonkey projects?

In the imminent future I think we need to concentrate on getting it right, i.e. fixing the most evident problems people have with SeaMonkey 2.0 (like the recurring high CPU load issue). The next step is to make use of more Toolkit features like the Places back-end for bookmarks which will enable syncing bookmarks with Weave, and to foster integration (Lightning, KompoZer; maybe instant messaging?). In the more distant future we'll have to keep an eye on what people expect from a modern Internet application and cautiously make the necessary adjustments.

What I would like to see is an evolution of usability (supporting the user's work flow), and an improved collaboration of Mozilla projects. The comm projects (Thunderbird, SeaMonkey and Calendar) are already cooperating quite nicely but I think there's room for improvement elsewhere.

A couple of people who see me regularly in person noted that my profile photo and other photos of me around the Web are a bit misleading because I've been sporting a full beard for the better part of this year. It probably won't survive 2009, but that's no reason not to share, so here's a quick iPhone snapshot that my friend Rey took.

It's getting a little bit (some might say that's not emphatic enough) out of control but I'm kinda digging it.

In the course of a recent debugging session, I discovered a limitation of web inspectors (Firebug, Dragonfly, Safari’s Web Inspector, et al.) that I hadn’t quite grasped before: they don’t show pseudo-elements and they’re not so great with pseudo-classes. There’s one semi-exception to this rule, which is Internet Explorer 8’s built-in Developer Tool. It shows pseudo-elements just fine.

Here’s an example of what I’m talking about:

p::after {content: " -\2761-"; font-size: smaller;}

Drop that style into any document that has paragraphs. Load it up in your favorite development browser. Now inspect a paragraph. You will not see the generated content in the DOM view, and you won’t see the pseudo-element rule in the Styles tab (except in IE, where you get the latter, though not the former).

The problem isn’t that I used an escaped Unicode reference; take that out and you’ll still see the same results, as on the test page I threw together. It isn’t the double-colon syntax, either, which all modern browsers handle just fine; and anyway, I can take it back to a single colon and still see the same results. ::first-letter, ::first-line, ::before, and ::after are all basically invisible in most inspectors.

This can be a problem when developing, especially in cases such as having a forgotten, runaway generated-content clearfix making hash of the layout. No matter how many times you inspect the elements that are behaving strangely, you aren’t going to see anything in the inspector that tells you why the weirdness is happening.

The same is largely true for dynamic pseudo-classes. If you style all five link states, only two will show up in most inspectors—either :link or :visited, depending on whether you’ve visited the link’s target; and :focus. (You can sometimes also get :hover in Dragonfly, though I’ve not been able to do so reliably. IE8’s Developer Tool always shows a:link even when the link is visited, and doesn’t appear to show any other link states. …yes, this is getting complicated.)

The more static pseudo-classes, like :first-child, do show up pretty well across the board (except in IE, which doesn’t support all the advanced static pseudo-classes; e.g., :last-child).

I can appreciate that inspectors face an interesting challenge here. Pseudo-elements are just that, and aren’t part of the actual structure. And yet Internet Explorer’s Developer Tool manages to find those rules and display them without any fuss, even if it doesn’t show generated content in its DOM view. Some inspectors do better than others with dynamic pseudo-classes, but the fact remains that you basically can’t see some of them even though they will potentially apply to the inspected link at some point.

I’d be very interested to know what inspector teams encountered in trying to solve this problem, or if they’ve never tried. I’d be especially interested to know why IE shows pseudo-elements when the others don’t—is it made simple by their rendering engine’s internals, or did someone on the Developer Tool team go to the extra effort of special-casing those rules?

For me, however, the overriding question is this: what will it take for the various inspectors to behave more like IE’s does, and show pseudo-element and pseudo-class rules that are associated with the element currently being inspected? And as a bonus, to get them to show in the DOM view where the pseudo-elements actually live, so to speak?

(Addendum: when I talk about IE and the Developer Tool in this post, I mean the tool built into IE8. I did not test the Developer Toolbar that was available for IE6 and IE7. Thanks to Jeff L for pointing out the need to be clear about that.)

I get mail on a number of contact email addresses @mozilla.org. Sometimes, people wrongly use these addresses to send support requests (for which I have a canned reply) or praise. Most of the praise is just "Wow, thanks!" but occasionally something comes in which is a bit out of the ordinary:

Dear dear guys and gals of Firefox s/w and bug fixes...

THANK YOU, THANK YOU, THANK YOU !!!!!

Thank you all for releasing me from the handcuffs, tyranny, vile and cat-o'-nine-tails of Microsoft Explorer and all its attendant BS, hype and unimaginable insane (and foreseeable!) problems!

In my heart and soul you are ALL heros (and hero-esses?!) and stars in the internet firmament !!!

May your light shine forever in the integalactic realm of truth, righteousness and ALL that is GOOD!

More power to your keyboarding souls and fingertips! :o)

Give yourselves (and/or each other [more fun, that!] :oD ) a great big hug!!!
(...or 'high-fives' if you're not yet that close! LOL )

Bless you all - may your souls forever surf the infinite with brightness with freedom of spirit and goodness!

Cheers,
<name removed>

I'm off to shine a bit more light into the integalactic realm of truth and righteousness...

A Google search for "Firefox 3.6 beta" offers this helpful result:

What's wrong with this picture?

The Zero Day Initiative has reported that Mozilla leads the industry with the fastest vendor response time to security bugs. Scroll down to Vendor Patch Time Statistics.

No surprise here, but nice to see it documented.

Today the Google folks disclosed that they have 30 million active users.

Chrome shipped its first public release 14 months ago and has managed to achieve a pretty large number of users in that time.

(For comparison, it took Firefox a full 8 weeks to add its most recent 30 million new users).

I've said this before, but really does deserve repeating that Google should go back to providing browser usage statistics for Google Search. They have a very large and globally distributed user base and that data would really help us all get a better picture of the global browser breakdown.

Remember when the Google Zeitgeist rocked?!

When the two primary sources disagree as much as Net Applications and StatCounter do, (Net Applications says Firefox has 24% of usage and StatCounter says it's almost 32%) adding a third big source seems like it could have nothing but a positive impact on understanding this world a little better.

Google, if you're reading this, please return to providing browser usage share in your Zeitgeist reports like you did before you started the Chrome project.

update: Wow. "Larry and Sergey recently gave the Chrome team a Founders Award, a multimillion-dollar stock bonus" That's pretty sweet. Lest anyone forget, Google has LOTS of money.

update2: Awesome tweet from @joedrew

We’re pleased to announce the availability of Postbox 1.1 BETA 1, which contains the latest and greatest improvements gained from our move to the Mozilla Firefox 3.5 platform.  Here’s what’s new and exciting about this release:

• Faster Performance - Postbox is now faster and more responsive than ever, so give it a spin!
• Better Looking Images - Postbox contains an improved graphics engine that produces sharper images with more accurate color.
• Improved UI Elements - For our Mac OS X users, Postbox now has more native looking UI elements, so it will fit right in with your Mac.
• More Reliable - 1.1 BETA 1 contains a number of reliability and stability fixes. Please see our release notes for the full set of changes.
• Localizations - Postbox localizations are now under way! If you would like to help localize Postbox, or just want to stay up-to-date with the latest localization news, please sign-up for our Localization Newsletter, or help us test a Language Pack.

Testing Postbox 1.1 BETA 1

Note: This BETA is available for testing purposes only. For increased stability and reliability, please use the latest production version, which is currently Postbox 1.0.2.

1) Download the Postbox 1.1 BETA 1 Release

• Windows
• Mac OS X

2) Tell us what you think!

We’re excited to hear your thoughts on Postbox 1.1, so please use our feedback site to report issues or ask questions about this release.

- The Postbox Team

Full Article

November 02, 2009 08:11 PM

October 30, 2009

Asa Dotzler -- tour of firefox

Full Article

October 30, 2009 08:46 PM

call for design/illustrator help

Full Article

October 30, 2009 08:25 PM

Gervase Markham -- Gerv Status 2009-10-30

Full Article

October 30, 2009 05:46 PM

October 28, 2009

Gervase Markham -- Ubuntu Crash Reporter Fail

Full Article

October 28, 2009 01:59 PM

SeaMonkey Team -- SeaMonkey 2 contributor interviews: Mnyromyr

Full Article

October 28, 2009 01:00 PM

October 27, 2009

Gervase Markham -- Gerv Status 2009-10-23

Full Article

October 27, 2009 01:05 PM

SeaMonkey Team -- SeaMonkey 2.0 - The Modern Internet Suite is Here!

Full Article

October 27, 2009 10:45 AM

Postbox Team -- Postbox 1.0.2 Now Available

Full Article

October 27, 2009 01:18 AM

October 26, 2009

Gervase Markham -- Sometimes Ranting Is Constructive

Full Article

October 26, 2009 09:46 PM

October 24, 2009

Postbox Team -- Postbox is Windows 7 Ready!

Full Article

October 24, 2009 12:21 AM

Boris Zbarsky -- Sane way to return arrays to JS from XPCOM methods

  void getSomething([optional] out unsigned long count,
                    [retval, array, size_is(count)] out whatever outArray);

  var myArr = foo.getSomething();

Full Article

October 24, 2009 12:19 AM

October 23, 2009

Asa Dotzler -- net neutrality wtf of the day

Full Article

October 23, 2009 11:02 PM

Vladimir Vukicevic -- Firefox Application Directory Lockdown

Full Article

October 23, 2009 07:08 PM

Ian Hickson -- Zarro Boogs

Full Article

October 23, 2009 08:00 AM

Last updated: November 25, 2009 05:15 AM