A day in Bugzilla

The last couple of days I've been going through loads of bugs in the mail & news component part of Bugzilla. The buglist is just never gonna stop growing, which is both a good and a bad thing.

A good thing since it means that people are using Mozilla and also using Bugzilla.

A bad thing since a lot of bugs are just simple to vague or simply lack information to reproduce them. Stuff like "I sometimes crash when sending email."

Well for new users of both Mozilla and Bugzilla I can understand why such bugs are filled. I think I even filled such bugs myself. Sometimes you just have no clue why Mozilla crashes.

So here I try to provide you with some good advice on how to make better bug reports.

How to make better bug reports:

  • try to reproduce the problem with a fresh/clean profile
  • make a mail protocol log and see if you can see any obvious bugs/problems
  • search Bugzilla and see if a similar bug has been reported
  • download the newest nightly build and see if the problem is still there
  • provide good and detailed information on how to reproduce
  • provide testcases etc like the source of the mail
  • try to debug the problem yourself
  • if you can build Mozilla Thunderbird yourself you can insert log comments and try to find the problem yourself

How to debug a problem yourself:

With all this in mind I like to take your through a session on how I tried to track down a bug without having access to building Mozilla myself.

The steps involves being able to sending mails from a command line, using LXR and DOM Inspector.

I was going through all the Windows bugs related to Attachments in the Mail & News component trying to find duplicates and old bugs that where no longer relevant. I then stumbled over the bug 151031 - gifs embedded in mail don't display and thought "perhaps I could try to find out why".

The bug was about some GIF images in a HTML mail that wasn't being displayed. A pretty common problem if you ask me. Normally the cause of problems like this is due to mailclients (like Outlook Express) sendings the wrong headers.

The reporter had already attached the source of the mail so resending it to myself was easy. I pasted the source of the mail into a file and then used sendmail to send it to myself like this:

/usr/lib/sendmail -v blabla@blabla.bla < mail.txt

with blabla@blabla.bla being my mailaddress.

First I verified that the images didn't display using the latest nightly build of Mozilla Mail. And sure no images. Next I tried using Outlook Express. All the images display nicely, so something was wrong or just different in Mozilla Mail.

I also verified that I could save the images from within Mozilla and later view them in the browser. This helped me verify that the images wasn't corrupt. So far so good or bad.

The reporter of the bug states himself that the use of Content-Base and/or Content-Location could be the source of the problem, so I started to play with these values.

The attached mail looked had headers like this:

Content-Base: "http://www.brunz.org/~waf/media/gallery/"
Content-Location: "http://www.brunz.org/~waf/media/gallery/"

So I tried removing the quotes from the URLs to see if that made any difference:

Content-Base: http://www.brunz.org/~waf/media/gallery/
Content-Location: http://www.brunz.org/~waf/media/gallery/

I send the mail again and this time the images was displayed just fine! So it had something to do with having quotes in the URLs. So I had to narrow it down if it was a problem in Content-Base and/or Content-Location. So I sent two more mails. One with quotes in Content-Base and one with quotes in Content-Location. And it turnes out that the problem was with Content-Base.

So an mail with the following header would fail to display the images:

Content-Base: "http://www.brunz.org/~waf/media/gallery/"
Content-Location: http://www.brunz.org/~waf/media/gallery/

When Mozilla has to display a mail it parsed the mail and then builds up some internal HTML to display the mail. So perhaps there where a problem with the internal HTML. Now I had a clue on why to start searching. I searched LXR for Content-Base.

I found that Content-Base was defined as HEADER_CONTENT_BASE in nsMailHeaders.h

I then search for HEADER_CONTENT_BASE found that the Content-Base is retrieved from:
http://lxr.mozilla.org/mozilla/source/mailnews/mime/src/mimethtm.cpp#113

and then a <BASE tag is inserted into the internal HTML at:
http://lxr.mozilla.org/mozilla/source/mailnews/mime/src/mimethtm.cpp#132

but the quotes from the Content-Base should be removed at:
http://lxr.mozilla.org/mozilla/source/mailnews/mime/src/mimethtm.cpp#136

So that didn't help much. I needed to be able to see the entire internal HTML. But how?

DOM inspector to the rescue. Via the DOM inspector I was able to inspect the mail window while viewing the mail. This is done like this:

  1. Select the mail your like to inspect
  2. Start the DOM Inspector via Tools -> Web Devlopment -> DOM Inspector
  3. Inspect the mail windows via File -> Inspect a Window -> your mail window
  4. Go to #document -> window -> hbox -> vbox (messengerBox) -> vbox (messagesBox) -> vbox (messagepanebox) -> browser -> #document -> HTML
  5. Right-click on HTML and select "Copy XML"
  6. Now you have the internal HTML on the clipboard

So by doing the above for both the mail that worked and the mail that didn't I was able to see the difference.

The interesting part of the internal HTML for the one that worked was:

<IMG _base_href="http://www.brunz.org/~waf/media/gallery/"
src="imap://bla@blablabla.bla:143/fetch%3EUID%3E.BLA.bla%3E11978? part=1.2&amp;filename=pic01.jpg"/>

The internal HTML for the one that didn't work was:

<IMG _base_href="http://www.brunz.org/~waf/media/gallery/"
src="cid:part1.09040402.02020908@routescience.com"/>

Why the imap:// didn't get inserted in the second mail with the quotes I haven't figured out yet.

This has been a small lession in how to debug a bug and how to help the developers so that they can spend lesser time in debugging problems and more time with coding.

If the above have helped the developer of the specific bug I have no clue about and it's not really the issue. The lession learned is the better bug reports your provide the better the chance you have for the bug to be fixed.


October 08, 2003 05:00 PM | Posted in Mozilla

Ads:

Back Next

6 Comments

Mozilla's bug tracker, Bugzilla, is awash with poorly documented entries. This makes the job of maintaining products such as Firebird a whole lot harder. Henrik Gemal has posted a guide to improving bug reports and debugging Mozilla. Take a look...

TrackBack from Bugzilla at October 8, 2003 07:31 PM | Permalink

"...help the developers so that they can spend lesser time in debugging problems and more time with coding."

this is my philosophy too, searching for dupes has become my hobby :)

Comment by oleg at October 9, 2003 03:36 AM | Permalink

No DOM inspector in *Birds Makes tracking bugs that much harder
and for the bug he talks about -
is the reason that the imap:// does not get put in because there already is a : ????

Comment by George Deka at October 10, 2003 04:27 AM | Permalink

This is a very very useful article. Despite all the efforts to get people to post bugs and the prominent bugzilla instructions on how to do it and what to include, I always feel a bit sheepish. Like I am not helping enough in my description. This actually gives a guy some tools.

Comment by vbenares at October 11, 2003 03:02 PM | Permalink

What a day ! They have to be so tired !

Comment by Dule at July 1, 2004 11:56 PM | Permalink

What a day ! They have to be so tired !

Comment by Dule at July 1, 2004 11:57 PM | Permalink

Post a comment




Remember Me?




Please enter the security code you see here

.
You're here: Home - A day in Bugzilla
Get the Mozilla Firefox browser