As I couldn’t find easy steps to follow to use Hotmail with Thunderbird 3, I decided to write my own article about it. And as screenshots are better than thousands of words, here you have. The screenshots are in french, but it’s trivial to understand which field is what.

Comme je ne parvenais pas à trouver une marche à suivre simple pour utiliser Hotmail depuis Thunderbird 3, j’ai décidé d’écrire mon propre article dessus. Comme des captures d’écran valent mille mots, voici pour vous.

Parameters for incoming emails

Parameters for outcoming emails

In my previous post, I talked about the new front page which will be used in Bugzilla 3.4 (it will very likely change again in Bugzilla 3.6 to look something like this). Now I’m going to talk about the new form to file bugs. Technically, it’s the same page as before, but we now hide some fields by default which we don’t consider to be critical when reporting a new bug.

The form to file bugs in Bugzilla 3.2 and older looks like this:

Full bug filing form

There are many fields which advanced users probably love to see when reporting a new bug, but they may look too complicated for newbies. With the idea that newbies know mostly nothing about the internals of Bugzilla, and that they probably won’t know what to set, we know display important fields only, by default:

Simple bug filing form

The information requested here seems small enough to not frighten new reporters. We could even imagine hidding the OS + hardware fields, as well as the component field, but I suppose the form would then look a bit too much like Hendrix. Anyway, it’s still a big improvement over what Bugzilla 3.2 displays to the user. And before you ask: yes, you can display all fields if you want to. Simply click the “Show Advanced Fields” link at the top of the page. Bugzilla will store your choice in a cookie so that you don’t have to worry about it in the future. Cool, isn’t it?

In my next post, I will show you how administrators can configure Bugzilla 3.4 to display some fields under certain circumstances only (for instance, on a per-product basis, or only for a given severity/priority, etc…) Another cool feature.

This is the first post about new features/UI improvements available in what will become Bugzilla 3.4. I realized that many readers don’t waste their time following links in articles; if a screenshot is not included in the article itself, they ignore links pointing to them. So I decided to insert as many screenshots as possible so that you have them immediately in front of you. And also, you can no longer complain that you didn’t know about such or such (bad) improvements when your Bugzilla installation is upgraded.

Today, I will talk about what will be the most noticeable UI change: the front page.

Front page displayed to logged out users

Above can you see the new front page displayed to logged out users. There are two major changes: the 3 big buttons in the center of the page, and the login form in the header and footer of the page (the login form is now in the header and footer of all pages). The first button (the green one) will let you file a new bug. Of course, it will display the login form first as you cannot file anonymous bug reports. The second button (the orange one) will display the search page (the specific or advanced search based on your cookie; the specific one being the default). And the third button (the blue one) will let you create a new user account. Below buttons can you see a search field, well known as a “quick search” (which is more powerful than the specific search form, which is mostly useless, but less powerful than the advanced search form. My vote to kill the specific search form completely, but that’s another story).

Some users already complained that there are now 6 ways to run searches from this single page: the “Search” link in the header, the “QuickSearch” form in the header (the one with the “Find” button) the big orange button in the middle, the “QuickSeach” form below big buttons, the “Search” link in the footer and the “QuickSearch” form in the footer (again, the one with the “Find” button). I agree this may look confusing to new users. Also, there are now 3 links to create a new user account: the “New Account” link in the header and in the footer as well as the big blue button. And finally, some complained that the “File a Bug” button is useless as you have to log in first anyway. Not ideal? Your feedback is welcome!

When you are logged in, the front page will look like this:

Front page displayed to logged in users

The only major difference compared to the logged out page is that the blue button now points to your user preferences. Also, the login form disappeared and is replaced by your login name, as in previous Bugzilla versions. We all agree that this page is suboptimal for logged in users, as much more useful data could be displayed instead of these big buttons (advanced users already use links in the header/footer of the page anyway). But we plan to improve it for Bugzilla 3.6.

Do you like it? Do you hate it? You have no opinion? Please let us know!

We finally released Bugzilla 3.2.3 and Bugzilla 3.3.4 last night, March 30. All existing Bugzilla 3.x installations will get automatic notifications within 24 hours (if administrators enabled this feature).

Bugzilla 3.2.3 fixes some important bugs:

• One of the security fixes implemented in Bugzilla 3.2.1 broke the ability to edit several bugs at once if the installation was using a shadow DB with the –read-only option (Bugzilla was trying to write into the shadow DB instead of the master DB). Installations not using a shadow DB are not affected by this issue.
• Due to our new token protection implemented in Bugzilla 3.2.1 to prevent unwanted bug changes, some Bugzilla clients were unable to edit bugs anymore as they had no valid token in hands. The XML format of bugs now contains a valid token which can be used to edit them (keep in mind that the token is generated based on the user ID, so you cannot use your own token with someone else, which is the goal of using tokens!).
• Saved searches with UT8 characters in their name no longer crash Bugzilla (again a regression due to one of the security fixes implemented in Bugzilla 3.2.1).
• Due to a change in MySQL 5.1.31 and newer, “SET SESSION max_allowed_packet” is no longer allowed, making previous versions of Bugzilla 3.2.x to fail. This problem is now fixed.
• Attachments now have the same token protection as bugs themselves. This is our last security fix related to cross-site request forgery (read the previous security advisory if you want to see which other areas were fixed in our previous security release).

All known regressions introduced in Bugzilla 3.2.1/3.2.2 have been fixed in Bugzilla 3.2.3. This means you really should upgrade your installation to 3.2.3.

Bugzilla 3.3.4 is our last development release before Bugzilla 3.4rc1. This means it’s feature complete and we will now only focus on bug fixes (enhancements are no longer allowed on this branch). Newly introduced features are listed in the Status Update. The most significant change is the new front page (screenshot). Feedback is much welcome! Please keep in mind that Bugzilla 3.3.4 got no QA at all, meaning that it’s potentially unstable. If you need a stable release, use Bugzilla 3.2.3.

To developers, note that we have reopened the trunk and new enhancements are again allowed. The current trunk version is Bugzilla 3.5 (which will become Bugzilla 3.6 when it’s stable). The 3.4 branch is tagged BUGZILLA-3_4-BRANCH.

On February 2, around 17:40 PST (Feb 3, 1:40 GMT), we happily released Bugzilla 3.3.2, 3.2.1, 3.0.7 and 2.22.7, which fixed several security issues. Less than 3 hours later, bug 476594 was filed on b.m.o, reporting a problem with srand() on mod_perl (read details in the bug), which is called when you call rand() in your code. This bug was undetected while writing security patches and while reviewing them, because most developers don’t use mod_perl on their test installations. Also, this problem hasn’t been detected on our “secret” mod_perl test installation, probably because race conditions couldn’t occur due to the low number of testers playing with it at the same time. But as soon as b.m.o upgraded to Bugzilla 3.2.1, the problem became very clear, and we have to address a big THANK YOU to Philippe M. “gozer” Chiasson to help us debug and fix the problem very quickly. Only 9 hours after the releases mentioned above, i.e. on February 3 around 2:40 PST (Feb 3, 10:40 GMT), Max Kanat-Alexander, our release manager, uploaded new tarballs on the FTP server, and the website was updated to announce the immediate release of Bugzilla 3.3.3, 3.2.2 and 3.0.8, with this single change in them (it’s actually a single line change). We didn’t release Bugzilla 2.22.8 as 2.22 doesn’t support mod_perl, and so is not affected by the problem.

That was a pretty intense and busy evening/night/morning (depends where you live on the planet) for Bugzilla developers: first, we had to commit 20 security patches (backports included) to CVS, then fix some QA scripts which were affected by the security fixes above, create and upload tarballs, update the website, then track the problem with srand() on mod_perl, review the patch, write and review the new security advisory and new release notes (it was the first time I had to do reviews from work…. you know, I’m teaching ), recreate and upload tarballs again, and finally update the website once more. Wow! But things seem to be going well now; no regression has been reported to b.m.o (yet).

Durant l’une de nos très sérieuses discussions sur #frenchmoz (lors de nos habituelles soirées à thème), nous sommes tombés sur cet article concernant les produits Mozilla. Il contient une très intéressante alternative au logo actuel de Firefox. Personnes sérieuses s’abstenir!

—

While talking on #frenchmoz, we found this article (in french) about Mozilla products. It contains a very interesting new logo for Firefox. Serious people, please abstain!

On planet.m.o, I see tons of tinyurl’s used to point to lists of bugs (a.k.a buglists). When you run a complex query, this is indeed the best solution for now (till bug 400063 is fixed), but in many cases, the query is simple enough to avoid tinyurl. How? Use QuickSearch!

For those who don’t know, QuickSearch is a built-in feature of Bugzilla. This is the small textbox on the left of the “Find” button you can see on all Bugzilla pages, in the header and in the footer. Maybe you think that all it can do is to get a bug ID and go to this bug when you click the “Find” button, but it can do much more than that!

Let’s take a few examples from recent posts on planet.m.o:

Example 1: Alex Faaborg’s post about polish bugs:

The “Hard Polish Bugs” link currently points to http://tinyurl.com/5e9dd7 but could be replaced by https://bugzilla.mozilla.org/buglist.cgi?quicksearch=prod%3ACore%2CFirefox%2CToolkit+sw%3A%22[polish-hard]%22+kw%3A%22polish%22 (click here for a try). How to get it? In the textbox mentioned aboved (or if you installed the Bugzilla Quick Search plugin, you can get the same result from here), you type:

prod:Core,Firefox,Toolkit sw:"[polish-hard]" kw:polish

“prod:” means “product”, “sw:” means “status whiteboard” and “kw:” means “keywords”. As you are querying in more than one product, you enumerate them separated by a comma. About the status whiteboard, I wrote [polish-hard] between quotes, but they are not mandatory in this case as there is no whitespace nor comma. But I’m used to add them by default for this field as most of the time I’m looking for something of the form [foo bar], i.e. with whitespaces. Without quotes, Bugzilla would read sw:[foo only and wouldn't know what to do with bar] (well, it knows what to do with it, but that’s not what you expect in this case).

You immediately see how to easily build the link for “Easy Polish Bugs“. All you have to do is to type:

prod:Core,Firefox,Toolkit sw:"[polish-easy]" kw:polish

and you get this URL.

Example 2: Mozilla Platform meeting minutes: 2008-10-28:

The “JS 1.9.1 Bugs” link about wanted bugs for JavaScript could easily be obtained by:

prod:Core comp:"JavaScript Engine" flag:wanted1.9.1+

which generates this URL. Here, “prod:” is again the product, “comp:” means “component”, and “flag” is… a flag. In this example, quotes are mandatory for the component because its name has a whitespace in it. Note that you don’t need to specify that you only want open bugs; that’s the default!

Example 3: Calendar Community Testday On Thursday, October 30:

The “some fixed tb-integration bugs that need to be verified” link could be obtained by:

RESO prod:Calendar resolution:FIXED flag:integration

which would generate this URL. Note that we start to type RESO, which means you want bugs with the RESOLVED bug status only. As I said above, the default is to only look for open bugs. If you don’t want to use this default behavior, you have to mention this as the first argument. Then, “resolution” is the bug resolution, here bugs marked as FIXED only. And finally, “flag:” contains a flag name with no +/-/?, meaning that you don’t care, you want all of them. Also, “integration” is not the complete flag name, it’s “tb-integration”. So Bugzilla would return all bugs matching the above criteria, and would also catch bugs having e.g. “fx-integration” if it exists.

Last trick of the day:

If you want to see all bugs waiting for your (super-)review, you can easily get them all at once typing e.g.:

flag:review?LpSolit

Just replace my nick on b.m.o by yours, of course. A shorter alternative is:

review?LpSolit

Bugzilla will automagically consider this last case as a flag due to “?” being detected in the string. That’s the only case where “flag:” is optional. If you suspect there may be requests for review in bugs which are already resolved (either RESOLVED or VERIFIED), you can ask for all of them thanks to:

ALL review?LpSolit

ALL is specified as the first argument to override the default and will make Bugzilla look for both open and closed bugs.

Note that you cannot do everything with QuickSearch. For instance, those testcases are not possible for now.

As I see more and more people asking when Bugzilla 3.2 final will be available for download, I decided to blog about it here: We will first release Bugzilla 3.2 RC2! This hard decision has been taken during our last Bugzilla meeting last week. The reason is that we did many checkins since RC1 and we may have potentially regressed something. But for all those who are impatient, you must know that Bugzilla 3.2 RC2 should be stable enough for production, and is currently in use by both Mozilla and RedHat, just to name a few. But be aware that QA is not complete yet, so there may be hidden (severe) regressions somewhere (even if I don’t think that’s the case; but who knows?).

While looking at Hendrix, I saw this captcha on the submission form:

captcha

I really have no idea what the second word is (10H? 101l?). And from what my doctor says, my eyes are working perfectly well. The audio alternative doesn’t work on Linux, so I cannot use it as a workaround. I really think such captchas are a bad user experience, especially for those with some disabilities (and in this case, even for those without disabilities).

As an alternative, why not suggesting something more simple? For instance: “How many triangles are not red in the figure below?”

alternative captcha

Unless the reader never went to school, he knows what a triangle is, and which color “red” is. I doubt a robot could easily parse the question (but I may be wrong).

Am I missing something?

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

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

While talking with gerv and justdave on IRC about the Committer’s agreement and asking whether MoCo was paying the stamp back, I suddently got a (bright?) idea: why not advertise Firefox, Thunderbird, Calendar, etc… by printing their logo on stamps? The only problem is that you cannot create your own stamps as you want. But this would be a cool way to bring Firefox & co. in all houses.

PS: if a chief of some post offices is reading this blog and you had no idea what to print in your next set of stamps, now you have one.

After reading Kairo’s article about bugs triaged in Seamonkey these last few weeks, I wanted to do a quick comparison between main products released by Mozilla: Firefox, Thunderbird, Seamonkey, Camino, Bugzilla, Calendar, and I also included Core and Toolkit. The comparison is interesting, as you can see below (click the image to make it larger… and readable).

As you can see, the two popular products of Mozilla, Firefox and Thunderbird, have many unconfirmed bugs. There are as many unconfirmed bugs as fixed bugs. This surprised me a bit when you know that with such a wide userbase and the QA team, bugs should become confirmed pretty quickly… or quickly be triaged as invalid or wontfix. Maybe are these products so popular that bugs are being filed much faster than they are resolved? I don’t know (someone more involved in these two products would know more).

The other six “products” (products as defined in Bugzilla) have a pretty similar behavior: only a few unconfirmed bugs, and two to three times more fixed bugs than open bugs (bugs marked as ASSIGNED and REOPENED have not been included as they are negligible compared to bugs marked as NEW). Does it mean triaging is more efficient and bugs fixed more quickly in these products, or does it mean these products are less popular, giving more time to developer teams to triage and fix bugs?

Anyway, my goal is not to say who is good and who isn’t in triaging and fixing bugs quickly. I just thought this graph was interesting. You are free to interpret it as you want.

Today, I tried to view a PDF file from within Firefox thanks to the Adobe Reader 7.0 plugin, but I couldn’t understand why it took so long to load the PDF. I first thought it was a big file, but Firefox was completely frozen for more than one minute. I was expecting that even if this was a large file, Firefox should still be responsive and that the navigation in other tabs should still work. When I looked at my shell window to kill the Firefox process, I realized the window was full of “expr: syntax error” error messages. Was the PDF file corrupted or was it a bug in Firefox? None of them! This was a bug in acroread itself as running it from the shell with no file specified was throwing exactly the same error. So why today and not these last few months?? The reason seems to be that Mandriva Linux 2007.1 released some updates for libgtk-x11 a few days ago and acroread was now failing. Fortunately, the fix is trivial and acroread (and Firefox using the Adobe plugin) is working fine again! So if you are running Firefox on Linux and use the Adobe plugin to view PDF files and wonder why nothing happens, this may be the reason.

Till the previous Tinderstatus release (0.2.3), the tinderboxen to watch were hardcoded and you had to edit some files manually to customize the list. In the latest release (0.2.4), you now have a UI which lets you select which trees to watch, and the status icon appearing in your status bar is updated immediately; no need to restart Firefox. If the tree you want to watch is not in the list, all you have to do is to add it to the extensions.tinderstatus.fullList pref in about:config. The list displayed in the UI will be refreshed with this new tree included and all you have to do is to select it to immediately see its status. Definitely a huge improvement over the previous release. Congrats to standard8 and myk for this release!

Je viens juste de demander sur IRC dans #firefox comment un administrateur peut partager une extension avec tous les utilisateurs; en d’autres termes, rendre l’extension globale. J’ai suggéré d’avoir une case à cocher, comme dans OpenOffice lorsqu’un administrateur installe un dictionnaire, ce qui est franchement très utile. Et la réponse franchement débile que j’ai reçue est qu’un administrateur ne représente que 0.01% des utilisateurs, et que de toute façon un administrateur sait comment utiliser des lignes de commandes pour faire cela, ou alors qu’il peut utiliser CCK. Grandiose! Donc non seulement vous devez être licencié ès Informatique pour faire une action semble-t-il aussi simple, mais en plus il vous faut apprendre chaque truc et astuce pour chaque logiciel que vous souhaiteriez utiliser ou tout simplement pour gérer votre installation.

Je veux juste dire une chose: tous les administrateurs ne sont pas des “pros” de l’informatique. Un bel exemple est l’enseignant à qui l’on demande de s’occuper du parc informatique de l’école dans laquelle il travaille, de maintenir les programmes à jour et de maintenir le système fonctionnel. Ce genre de tâches n’est pas exactement le point fort premier d’un enseignant. Et ce n’est qu’un exemple parmi d’autres (imaginez n’importe quelle autre “petite” entreprise qui essaie de se débrouiller seule). Et même à la maison, lorsque vous essayez de partager une extension avec votre femme et vos enfants parce que vous jugez qu’elle peut être utile, là aussi vous ne souhaitez pas passer par la ligne de commande que de toute façon vous ne connaissez pas, malgré que votre système d’exploitation dit que vous êtes “l’administrateur” de votre système.

Cela veut-il dire que Firefox est conçu pour les mordus de l’informatique seulement?

–

I just asked in #firefox on IRC how an admin can share an extension with all users (a.k.a. globally). I suggested why not having a checkbox on installation which you can mark if you want the extension to be available to all users? This is what you see when an admin installs a new dictionary with OpenOffice 2, and this is really helpful! A reply I got was of the form “admins are only 0.01% of users, and admins know how to use command lines to do it, and there is CCK too”. Great! I have never heard of something more ridiculous than that. So not only must all admins have a PhD in Computer Science to use Firefox in an optimal way, but they must also learn all the tricks from all the software to manage their network.

I just want to say one thing: not all admins are developers/hackers nor do they have time to search in the documentation which command line (if any) to type. One precise example I have in mind is teachers who have been asked to manage the network of the school they are working in, and to keep softwares up-to-date and to have everything working correctly despite administering a network for some hundreds of users is not their exact primary skill. Even you at home, when you install an extension and want to make it available for your wife and children, because it’s exactly what your family needed, is not necessarily an “expert”, even if your settings say you are an admin.

So is Firefox for advanced users only?