You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

Skip to main content

How to pre-screen Browser-General bugs

Maintained by Gerv

Why should I read this?

As Mozilla progresses towards becoming a usable product, it has begun to receive a staggering number of bug submissions, of varying quality and relevance. Mozilla engineers can spend their limited time evaluating this torrent of bugs -- or they can be fixing the bugs and implementing the features already deemed critical. Many of these land in a Bugzilla component called Browser-General.

Each bug that we ensure is up-to-date, complete, and relevant before it reaches a Mozilla engineer will enable him or her to fix more critical bugs or implement more cool features.

I agree. How can I make a difference?

First, look at the list of untouched Browser-General bugs that need pre-screening. Every one of these bugs needs a conscientious and thoughtful person like yourself to determine their merit and engineering destination.

Here's how.

Bugzilla receives lots of less-than-useful bug reports. A "less-than-useful" bug report is one that does not efficiently lead an engineer to fixing a problem. Bugzilla also receives "bug reports" ranging from job openings to resignations, Netscape technical support requests and random Netscape venting to personal ads!

You'll quickly get a feel for which bugs are worth an engineer's time. It normally boils down to these four steps:

Can you easily reproduce this bug report on a current build?

...Or does the bug report lack accurate steps to reproduce, along with clear expected results and actual results, as specified in the Bug Writing Guidelines? Is the bug's description ambiguous like mozilla crashes or browser problem, or does it accurately describe an actual problem?

If you can reproduce it, try and beef up the bug report yourself to include the missing information. You may also wish to ask the bug reporter for missing information, refer them to the Bug Writing Guidelines for future bugs, and encourage them to use the Bugzilla guided entry form. If you can't reproduce the bug -- and the bug reporter can't or won't help -- feel free to discard the bug as INVALID or WORKSFORME.

Does the bug report identify one specific problem?

Less experienced bug reporters try to save time by writing a single bug report that raises many different, unrelated issues. Please feel free to resolve these bugs as INVALID, and explain to the bug reporter to file a separate bug for each issue: a bug report should contain no more than one issue, for a multitude of reasons (courtesy of John Morrison):

  • Layout bugs go to layout, and networking bugs go to networking engineers. Distinct bugs enable work to proceed in parallel.
  • When a bug is fixed, it must be verified against a specific test. Bug reports that list multiple conditions and problems are difficult to verify.
  • Bug reports that list multiple bugs may mean that some problems noted do not get addressed.
  • Bug reports that list a single bug are more likely to be resolved in a timely fashion.
...and can an engineer actually fix it?

Less experienced bug reporters will submit bugs that are general complaints about Mozilla, and which do not distill to a fixable bug. These can also be marked as INVALID.

For example, let's look at two performance bugs: while the less-than-useful bug simply says that Mozilla's interface is very slow, the useful bug identifies a specific, reproducible task that is slower, and by what magnitude.

Does this bug look like a duplicate report of a known issue?

Lots of bugs are reported many, many times. If you think it might be a duplicate, consult the Most Frequent Bugs list, and search Bugzilla.

If you think it might be a duplicate -- but aren't sure -- just add your comments into the bug report. Somebody down the road will be thanking you for your thoughtfulness.

Suggested responses to common crummy bugs

Here are suggested responses to common types of bad bug reports that bug screeners encounter. They copy and paste nicely using Mozilla. Feel free to close out bugs if you don't receive a response from the bug reporter after 5 days.

The bug report was reported using an old build... (e.g. 3+ weeks old, and if you can't reproduce the bug on a current build)
<reporter e-mail> - <buildID> is too old a 
build to report bugs against now. The problem you are reporting may well have 
been fixed already. 

Could you please download a recent nightly build from 
<http://www.mozilla.org/releases/nightly.html>, and then let us know if you 
still see this problem?

Thanks,


<sign>
The bug report isn't very useful...
<reporter e-mail> - could you please read the Bug Writing Guidelines 
at <http://www.mozilla.org/quality/bug-writing-guidelines.html> to see the 
kinds of information we need in a bug report. Please report back with more information 
(like BuildID and steps to reproduce) after reading those guidelines and consider 
using the guided form to report future bugs. 

The guided entry form can be found at <https://bugzilla.mozilla.org/enter_bug.cgi?format=guided> 
Thanks for your help in testing Mozilla.

<sign>
The bug report is a Netscape 6 or 7 bug, the reporter didn't test Mozilla, and you can't reproduce the problem in Mozilla...
<reporter e-mail>  - Thanks for your input, but the correct place 
for reporting Netscape 6 or 7 bugs is <http://home.netscape.com/browsers/6/feedback/>. 
Unfortunately, mozilla.org doesn't have the resources to cope with their bugs as 
well as our own. :-) Additionally, lots of stuff which is broken in their version
is now fixed in ours.

However, if you see this problem in a recent build of Mozilla, feel free
to return and ask for this bug to be reopened.

Marking INVALID (don't take it personally, Bugzilla doesn't have a politer option ;-)

<sign>

Tutorial originally written by Eli Goldberg. Thanks to John Morrison, Sean Richardson, Matthew Thomas, Jan Leger, and everyone else who contributed their two cents to this tutorial.