Bugzilla 4.1.1 Development Release

Less than a month after our release of 4.0, we have our first development snapshot, Bugzilla 4.1.1 available for you! This is our first release towards what will eventually be 4.2, and it’s got a bunch of new features. Here’s a really quick overview of what’s new in 4.2:

  • Bugzilla now sends bugmail in both text and HTML.
  • You can disable component, milestone, and version values.
  • You can now create an attachment by pasting it into a text field.
  • If you are using a modern web browser, then after you update a bug, the URL in your web browser will be the URL to view the bug. (So, pressing refresh will simply let you see the bug, and not try to update it again. Also, if you have “session restore” in your browser, it will load the bug instead of an error page.)
  • Comments are no longer automatically word-wrapped by the server, but are instead word-wrapped in the browser. This means that they are no longer exactly 80 characters wide–they are now wider.
  • Tabular reports now look nicer and can be sorted.
  • There is a new link, (take) that appears next to the Assignee field and allows you to assign a bug to yourself.
  • Bugzilla can now run on SQLite as its database system. This is experimental and should not yet be used for production systems.
  • You can now say that a custom field should only appear when any of a set of values are set on another field. (So, for example, you could say that a single field appears in multiple products.)
  • You can now choose to optionally (as a user preference) not have Quicksearch search bug comments.
  • The default list of columns for search results is now more sensible.
  • Bugzilla now audits most changes to most things in the system, and stores this auditing information in a table in the database. There is not yet a UI into this table.
  • The system for deciding how and when to store attachments on the disk (instead of in the database) has been simplified.
  • long_list.cgi, xml.cgi, and showattachment.cgi are gone. (They were not in use since a very old version of Bugzilla.) We also removed sidebar.cgi (the sidebar) because it wasn’t in use and future versions of Firefox will not support it.
  • You can search for bugs based on the number of comments that they have.
  • Also, you can add “number of comments” as a column in your search results.
  • Boolean charts now work sensibly for almost all fields. For example, searching for “CC is not equal to” now finds bugs where that user is not CC’ed, instead of all bugs that have at least one CC who isn’t that user. However, some of the old “magical” boolean chart functionality (such as searching for only attachment flags if you specify both a flag criterion and an attachment criterion) is temporarily missing while we redesign the search system.
  • By default, searches now only return 500 results. (You can click a link to see more.) Searches may also now never return more than 10,000 results.
  • The “See Also” field now accepts many more types of URLs. It also accepts simple bug numbers to refer to a bug in your current Bugzilla. Adding a local bug number to the “see also” field will also cause that bug’s “See Also” to point to this bug.
  • If you only have the “editcomponents” privilege for one or more products, you can now manage Flags for those products.
  • You can now specify “limit” and “offset” as URL parameters for all searches. These work much like their similar SQL equivalents.
  • You can now require a certain level of password complexity for your users.
  • When you run checksetup.pl to create a new Bugzilla database, it will print out far less information than it used to.
  • Almost all of the important information that checksetup.pl prints out can now be localized.
  • There is now a specific directory in bz_locations (in Bugzilla::Constants) for where the pre-compiled templates are stored, that can be customized.
  • This release contains an initial implementation of a new tags system. The new UI for this tags system has not yet been implemented.
  • There is now a special group for moderating quips, so you don’t have to be an admin.
  • Bugzilla can now automatically detect the correct encoding for text attachments that aren’t in UTF-8.

Those are most of the major new changes that are in 4.1.1 over 4.0. We also have many other features planned for 4.2.

We hope that you enjoy testing Bugzilla 4.1.1 and we would love to hear your feedback, both on how the new features work and any bugs that you may find!



16 thoughts on “Bugzilla 4.1.1 Development Release

    1. It helps make the formatting much clearer (for example, when you change a long text value, it’s much easier to read the new and old values, this way). It’s actually even easier than turning it off–all the messages are sent as “multipart/alternative”, so all you have to do is tell your email reader that you prefer reading text, and you will see all the messages as text.


        1. Oh, yeah, it *will* unfortunately make them larger.

          When this concern was raised during development, I pointed out that my entire last nine years of bugmail (which I have kept all of) has amounted to no more than 467MB of text. That means that three years of HTML bugmail would have been about 1GB or 2GB of text. That’s a lot more, but that’s *nine years*. That would average out to about 100MB a year for HTML bugmail, which doesn’t seem like too much storage space, particularly given the fact that bugmail is relatively disposable (at least theoretically) since the same data should be contained in Bugzilla itself.


  1. Ah, interesting. As a plain user and occasional triager (not a developer) of bug-tracked software, there are many things there about which I am indifferent (in the sense of: neither for nor against), but there are a couple which caught my attention:

    * After updating a bug, we come back to a “show bug” URL, not a “process bug” URL.
    — For an absent-minded guy like me, this is invaluable. This way after saving the current session, then coming back to it with the next browser nightly, there will be much less risk of losing the tab to a bug if I forgot to click the bug number after posting a comment or making some other change.

    * Comments are not automatically word-wrapped on the server anymore.
    — I expect that this will mean reflowing the text according to the actual width of the browser window, which would probably mean a much nicer display in the user’s browser at very little cost (or maybe even some reduced cost) to the server.

    If only for these improvements (especially the former) I can’t wait for when BMO will decide to upgrade its current “3.6.4+” release to that “4.1.1 or later”.

    1. Hey Tony! Yeah, that show_bug URL thing will help a lot of people. šŸ™‚

      It’s *possible* for the text to now reflow to the browser width, but it doesn’t because studies show that narrower columns of text are easier for people to read. So we do set it to a certain fixed width still, it’s just wider than it used to be. Also, this is advantageous for people who write in Chinese, Japanese, or Korean, because their text will now be wrapped to the same width as other languages. (So it will look better if you mix languages in a single comment.) There were also other good reasons to handle this, such as the weird thing that used to happen when you would type “bug” on one line and then “2” on the next line and Bugzilla would think you were making a reference to a bug.


      1. Hi Max,
        Yeah, maybe smaller widths are reasier to read for most people but I was thinking of what would happen if the browser window was made narrower than usual.
        Your comment reminds me of a bug I’ve seen in the past (now fixed I think) where the server would break the line between “bug” and the bug# and then forget to make it a link. What you mention would be the converse of that bug, and might perhaps have been introduced by its fix.

        Any ETA at the BMO implementation of Bugzilla?

        1. Hey. Yeah, I believe both the bug and its converse will be fixed by this.

          4.1.1 is a development release of Bugzilla, and since about 2006 or so, bugzilla.mozilla.org only runs stable releases. The stable release we’re leading up to is 4.2, which we expect to be released some time in Q4 of 2011. After that, it often takes up to three months for Mozilla to upgrade. So you may be waiting until 2012 to see some of these features there.


  2. Thanks for the great release!

    Works great. The HTML email is great..although I guess it could be styled better?

    Also, automatic word-wrapping works as advertised but not in the sent emails.

    Thanks again!

    1. Thanks! Totally agree about the styling of HTML email. We have a few bugs open about that.

      And yes, it is not yet reasonably possible to do automatic word-wrapping in most email clients for preformatted text.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.