If you need help with Mozilla software (for example with Firefox or Thunderbird), use one of the available support options. Do not edit this page.
If you're new to Mozilla QA, you may want to try getting help from the more experienced contributors. See the Community section on the QA page for pointers. If you're going to report a Firefox bug, you can also get assistance in the <tt>#firefox</tt> channel on irc.mozilla.org. There's also an article specifically about filing Firefox bugs.
Effective bug reports are the most likely to be fixed. These guidelines explain how to write such reports.
- Be precise
- Be clear - explain it so others can reproduce the bug
- One bug per report
- No bug is too trivial to report - small bugs may hide big bugs
- Clearly separate fact from speculation
- Reproduce your bug using a recent build of the software, to see whether it has already been fixed.
- Search Bugzilla, to see whether your bug has already been reported (tutorial).
Reporting a New Bug
If you have reproduced the bug in a recent build and no-one else appears to have reported it, then:
- Choose "Enter a new bug" (that form incorporates parts of these guidelines)
- Select the product in which you've found the bug
- Fill out the form. Here is some help understanding it:
Component: In which sub-part of the software does it exist?
This field is required. Click the word "Component" to see a description of each component. If none seems appropriate, look for a "General" component.
OS: On which operating system (OS) did you find it? (e.g. Linux, Windows XP, Mac OS X.)
If you know the bug happens on more than one type of operating system, choose "All". If your OS isn't listed, choose Other.
Summary: How would you describe the bug, in approximately 60 or fewer characters?
A good summary should quickly and uniquely identify a bug report. It should explain the problem, not your suggested solution.
- Good: "Cancelling a File Copy dialog crashes File Manager"
- Bad: "Software crashes"
- Bad: "Browser should work with my web site"
Description: The details of your problem report, including:
Overview: More detailed restatement of summary.
Drag-selecting any page crashes Mac builds in the NSGetFactory function.
Steps to Reproduce: Minimized, easy-to-follow steps that will trigger the bug. Include any special setup steps.
1) View any web page. (I used the default sample page, resource:/res/samples/test0.html) 2) Drag-select the page. (Specifically, while holding down the mouse button, drag the mouse pointer downwards from any point in the browser's content region to the bottom of the browser's content region.)
Actual Results: What the application did after performing the above steps.
The application crashed.
Expected Results: What the application should have done, were the bug not present.
The window should scroll downwards. Scrolled content should be selected. (Or, at least, the application should not crash.)
Build Date & Platform: Date and platform of the build in which you first encountered the bug.
Build 2006-08-10 on Mac OS 10.4.3
Additional Builds and Platforms: Whether or not the bug takes place on other platforms (or browsers, if applicable).
Doesn't Occur On Build 2006-08-10 on Windows XP Home (Service Pack 2)
Additional Information: Any other useful information.
For crashing bugs:
- Win32: If you receive a Dr. Watson error, please note the type of the crash, and the module that the application crashed in. (e.g. access violation in mozilla.exe)
- Mac OS X: When the application crashes, click the "Report" button in the notification window that appears, then copy all the text from the text box under the message "Problem and system information" and include it with your bug report. There's no need to send the bug to Apple, so just click the red close box at the top of the window.
- Unix: Please provide a minimized stack trace, which can be generated by typing <tt>gdb mozilla core</tt> into a shell prompt.
Date/Time: 2006-12-26 12:15:20.089 -0500 OS Version: 10.4.8 (Build 8L2127) Report Version: 4 Command: firefox-bin Path: /Applications/Firefox.app/Contents/MacOS/firefox-bin Parent: WindowServer  Version: 220.127.116.11 (18.104.22.168) PID: 114 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x000000ca Thread 0 Crashed: 0 libxpcom_core.dylib 0x0186329b AppendUTF8toUTF16(char const*, nsAString_internal&) + 31 1 libxpcom_core.dylib 0x01822916 nsTextFormatter::smprintf_free(unsigned short*) + 3248 ... (many many more lines like this) ...
Add an attachment: You can attach relevant files to a bug report. Debugging information more than 20 lines long should be supplied this way. Also, if you have an HTML file that demonstrates the bug, you should attach that. You can only attach one file during initial submission so if your demonstration needs more, revisit the newly filed bug to do this part. Attach any subsidiary files (such as images) first and then edit the HTML file to point to the new URLs of the attached files before uploading, so the demo is self-contained. Ask before attaching more than five files.
Double-check your report for errors and omissions, then press "Commit". Your bug report will now be in the Bugzilla database.
HOW can't find the 'Commit' button - - what a joke!!
Original document information
- Author(s): Gervase Markham, based on an original by Eli Goldberg
- Other Contributors: Claudius Gayle, Jan Leger, Felix Miata, Peter Mock, Chris Pratt, Chris Yeh, and others.