Ehsan Akhgari's blog

Some of you might have noticed, but the test_is_Ehsan_available.js test has been failing intermittently for the past few days.  The reason seems to be frequent network problems and other complications that he's been writing about, and unfortunately it doesn't seem like there is anything our wonderful IT team can do to bring him back up.

I finally got to blog about this: the Persian localization of Firefox 3.5 Beta 4 was released last week among the 70 localizations in that release.  This is the second release of the Persian localization team, and the release is currently in Beta.  We are hoping to prepare everything for the first official release of Persian Firefox with the release of Firefox 3.5.

Ever since bug 404536 has landed, a number of users have been angry.  What that bug did was removing the context menu for HTML form elements.  This change annoyed mainly two classes of users: those who were accustomed to those context menus, and those who used extensions which add menu items to the context menus for form elements (along with other elements, possibly), most notably, Firebug.

Until now, localization projects which did not have a Windows code-page assigned to them were out of luck for localizing the installer and updater user interfaces for all Mozilla-based applications.  We all know that code-pages are evil; here are the main problems encountered with code-page based localization of these two applications:

The first Persian Firefox builds (built by Tinderbox) are available!  These builds, according to Persian Mozilla Dashboard are 86% percent complete.  Nearly all parts of the browser are translated.  The remaining things to translate include a number of security error messages and UI strings, and the installer (which is in fact translated, I'm just working on bug 305039 to make the installer Unicode, so that we can have a useful Persian installer).  These will hopefully be finished soon as well.

I thought I'd blog about this, hoping some web developers may find it useful.

Previously, Mozilla's HTTP protocol implementation did not check the presence of the Accept-Ranges response header.  The job of this header is to tell the client whether it can perform HTTP range requests, and if so, in what units should it express its range requests.  Practically, the only unit used by web servers is bytes, so this header's job in the real world is to tell the server whether it can perform range requests at all.

I gave a talk on Mozilla Software testing approach as part of my Software Testing course.  You can find the slides (built using S5) here.  I introduced a number of tools that we use for automated and manual testing, and also gave an overview on parts of the process employed to use the tests in real life.

You can grab the slides.  I hope that they'll be useful to you.

Started by Benjamin.  Here are my results.

Look what we're building!