Home > Contribute > BugReportingGuidelines
Note: the bug tracking system described on this page is no longer in use. Active development currently takes place in the forums.
Your bug reports can help us make K-Meleon a better browser. For this
to come true you should take the time to write your reports carefully.
The better a bug report is written, the more likely is it that someone
can use the report to find a fix. It should still take you just a minute
or two to file a bug. Follow these guidelines when reporting what you
have found:
Step 1: Select the right place to write your report:
a) Bugs found in a beta releases are generally not kept in the BTS.
(Actively developed components are broken and repaired on short
notice...) Please communicate with the Developers list before filing
any bugs found in unofficial releases. See step 4 on what
information to send. But, make sure a bug report is filed if the
problem is not be fixed shortly.
b) Bugs that have been reported before should not be reported anew.
Always check the Bug Tracking System to see if anyone else has
reported a similar bug as what you have found. If there is a bug,
please add any extra information you have that can help identify and
fix that bug. (Too many of the current bug reports are very vague
and hard to understand.) See step 4 on what information to add.
c) Newly found bugs in official releases should be filed as new
bugs. Select Report a Bug to open a new bug report. If you have
encountered more than one bug at the same time, please file separate
reports for each bug to make the bug tracking easier.
Step 2: Select component, severity and owner.
You will usually not have to bother about the bug report dropdown
fields, but if you are able to identify the faulting component this
might help us to quickly set the right person in charge of the bug.
Please don't try to push "your" bug by setting an extra high
severity, it doesn't work that way. Best way to have a bug fixed
quickly is by providing outstanding information under step 4 below.
Step 3: Write a short, one-line, "summary".
It is _very_ important that you write a summary that provides a good
description of your bug. This will often be the only text read when
searching, grouping and judging the relations of different bugs
later. Take your time and think carefully! If the bug involves a
specific plugin or component, it can be wise to include the name of
that in the summary.
Step 4: Write a detailed description of your bug.
Tell us, short and to the point, but yet detailed:
- What OS you're using.
- What you were doing when the bug happened.
- What you expected to happen and what actually happened.
- The steps that we need to follow to recreate your bug.
- If the bug just happened once or happens over and over again.
- The URL for the web site if the bug happens at a specific web site.
- Whether other Mozilla browsers are affected too.
Try find out if the bug depends on whether one or the other plugin
is loaded or not, whether changing some preferences give different
results, or anything else you can think of that can be of
importance. But don't make guesses in your report! This point is
worth spending some time on. You want help with having the bug
fixed. We want help with figuring out what goes wrong.
If a bug involves rendering, networking, javascript, or third party
plugins chances are that it is not a bug in the K-Meleon source.
Please see if other Gecko-based browsers are affected too (such as
Netscape, Mozilla, MfcEmbed) and try find a relevant bugzilla entry
to add to your report in that case.
Always use your best English when writing a bug report; aim for
proper language, grammar, punctuation and so on. Standard
compliance is the best way to guarantee that what you write is
interpreted the way you intend. ;-)
Step 5: Click on Submit to file your bug!
We will follow-up on your report as soon as we can. The more
information you provide us, the more likely that we can identify and
fix the bug you have found. With your help, we will clean up our
K-Meleon bugs as fast as possible!