If you need help with Mozilla software (for example with Firefox, Seamonkey or Thunderbird), use one of the available support options. Do not edit this page!
This page assumes you'd like to contribute to the Mozilla project by collecting enough information to enter a useful bug report in Bugzilla, the Mozilla's bug tracking system. Thank you!
If you're new to reporting bugs, 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 #firefox channel on irc.mozilla.org. For other projects like Thunderbird, Seamonkey, ... you can find the appropriate channel on IRC.
How to report a bug
Open a new bug report for each issue!
Only so an effective bugfix-workflow will be possible.
Other details you should heed
- Figure out the steps to reproduce a bug:
- If you have precise steps to reproduce - great! - you're on your way to reporting a useful bug report;
- If you can reproduce occasionally, but not after following specific steps, you must provide additional information for the bug to be useful;
- If you can't reproduce the problem, there's probably no use in reporting it, unless you provide unique information about its occurrence;
- Make sure your software is up to date. Ideally, test an in-development version to see whether your bug has already been fixed (e.g. Firefox Beta, Aurora, or bleeding-edge Nightly).
- When reporting a Firefox bug, first check if you can reproduce the bug in a new Firefox profile. If the bug only happens in your existing profile, try to figure out what settings, extensions, or files in your profile are needed to reproduce the bug.
- If the bug seems egregious (i.e. obviously affecting a large portion of users), there's probably something unusual about your setup that's a necessary part of the steps to reproduce the bug. You have much better chances of figuring it out than a developer who does not have access to your system.
- If the bug falls into one of specific types of bugs listed in a section below, it may still be be useful even if you can't reproduce it in a new Firefox profile.
- Open the Enter a new bug form, which will guide you through most of the bug reporting process:
- Create a Bugzilla account if you don't have one already, select the product having the bug;
- Enter a clear unique summary as described below; check if the bug has already been reported (If you want to be more thorough, there's an advanced guide to Screening duplicate bugs.)
- Provide precise steps to reproduce, expected results and actual results as described in the following section;
- Provide additional information (also described below), especially if you can't reproduce in a new profile and/or reporting a crash, memory usage, performance, regression bug or if the problem is with specific web site.
- If you have multiple issues, please file separate bug reports.
Writing a clear summary
How would you describe the bug using approximately 10 words? This is the first part of your bug report a triager or developer will see.
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"
- Good: "Down-arrow scrolling doesn't work in <textarea> styled with overflow:hidden"
- Bad: "Browser should work with my web site"
Writing precise steps to reproduce
How can a developer reproduce the bug on his or her own computer?
Steps to reproduce are the most important part of any bug report. If a developer is able to reproduce the bug, the bug is very likely to be fixed. If the steps are unclear, it might not even be possible to know whether the bug has been fixed.
| What should you include in a bug report? | Good (precise) example | Bad (imprecise) |
|---|---|---|
| Indicate whether you can reproduce the bug at will, ocasionally, or not at all. | I can reproduce by following these steps: | |
|
Describe your method of interacting with Firefox in addition to the intent of each step. |
1. Start Firefox by clicking on the desktop icon |
Open Gmail in another window |
|
After your steps, precisely describe the observed (actual) result and the expected result. Clearly separate facts (observations) from speculations. |
Expected results: My Inbox displays correctly. Actual results: My inbox displays the message 'Your browser does not support cookies (error -91)'. |
"It doesn't work" "Page displays incorrectly" |
Providing additional information
The following information is requested for most bug reports. You can save time by providing this information below the Expected results. If you need to attach multiple files, you can do so after submitting the report.
For specific types of bugs
If you are reporting a crash bug, please include a Breakpad ID or attach stack trace, and include the crash signature in the bug summary as well as in the Crash Signature field.
If you are reporting a memory use or leak bug, please attach the output of about:memory. Ideally, find steps to reproduce an increase in what is shown in about:memory (even after clicking the "Minimize memory usage" button at the bottom). If you have trouble finding steps to reproduce, try the Firefox Support page titled High Memory Usage. If you are a C++ developer, more precise tools are available.
If you are reporting a bug about slowness or high CPU usage, please provide a link to the performance profile in the bug.
If you are reporting a hang (beachball on OS X or "not responding" on Windows), please follow the instructions in How to Report a Hung Firefox.
If you are reporting a bug involving a Flash hang, please visit https://wiki.mozilla.org/Flash/Hang_Debugging to learn how to provide useful information for developers.
If you are reporting a bug involving a specific web page, please try to make a reduced testcase and attach it to the bug report. If you don't have time or expertise, please report the issue to webcompat.com instead, where our volunteers will do this for you.
If the bug was recently introduced, finding a regression window can help identify the cause of the bug.
What if my bug seems "random" or "intermittent"?
For most Firefox bugs
You should provide the following information for most Firefox bugs.
| What should you include in a bug report? | Example |
|---|---|
| Indicate if the problem can be reproduced using a new Firefox profile and any changes you need to make in order to reproduce. | The problem can be reproduced in a new profile, but only if Options -> Privacy -> Tell sites that I do not want to be tracked is selected. |
| If you can only reproduce with an existing profile try to figure out what settings, extensions, or files in your profile are needed to reproduce the bug. If you skip the step, save the troubleshooting information from about:support to a file and attach it to the bug report. | I can't reproduce in a new profile, about:support information from the offending profile is attached. |
|
Indicate if the problem can be reproduced using the latest Nightly build. Include the Build ID from about:support. If possible, test using the new Firefox profile you created. If you need to test the Nightly build with your regular profile, you might want to back up the profile first, since the pre-release build may corrupt your data. |
The problem can be reproduced on the latest Nightly (Build ID 20150331030204). |
Original document information
- Author(s): Jesse Ruderman, Gervase Markham
- Other Contributors: Eli Goldberg, Claudius Gayle, Jan Leger, Felix Miata, Peter Mock, Chris Pratt, Chris Yeh, and others.
Advanced
Finding the correct product and component
You will be asked to categorize your bug into a "product" and a "component" within that product, in order to direct your report to the correct developers.
If you're using Firefox, the bug is most likely in "Firefox", "Toolkit", or "Core".
- List of components in the "Firefox" product - Most parts of Firefox that you interact with directly
- List of components in the "Toolkit" product - Interface widgets and some frontend features
- List of components in the "Core" product - Web page rendering, networking, etc.
When in doubt, search for similar bugs and see what component they are in.
If none of the components seem appropriate, look for a "General" component in the most appropriate product.
General Outline of a Bug Report
Most of the following article has been merged into this page from QMO: How to write a proper bug
- Summary: How would you describe the bug in less than 60 characters? It should quickly and uniquely identify a bug report as well as explain the problem, not your suggested solution. Good: "Canceling a File Copy dialog crashes File Manager" Bad: "Software crashes" Bad: "Browser should work with my web site"
- Component: In which sub-part of the software does it exist? This field is a requirement to submit any bug report. Click the word "Component" to see a description of each component. If none seems appropriate, highlight the "General" component.
- Version: select the earliest Version with what the problem can be reproduced:
- Developers will use that information to narrow down the commit what introduced a regression
- QA staff needs that information to distinguish bugs with similar symptoms, but different roots.
- Bugs what definitively appeared in different Product Versions probably will have different roots
- But Bugs what started with the same Product Version probably are DUPLICATEs
- Trunk does not allow any useful query. We have Trunk version bugs from beginning of the project until today, no common characteristics at all what can be tagged with this version. Avoid Trunk, replace it by precise information with what version the problem appeared if you can.
- OS: On which operating system (OS) did you find it? (e.g. Linux, Windows XP, Mac OS X.) Example: "If you know the bug happens on more than one type of operating system, choose "All". If your OS isn't listed, choose Other".
- Description: The details of your problem report, including:
- Overview: This is a larger detailed restatement of the summary. An example would be: "Drag-selecting any page crashes Mac builds in the NSGetFactory function".
- Build Id: To find this either go to the "about:support" page via the location bar or, if you have MozQA's Nightly Tester Tools extension, then go to Tools | Nightly Tester Tools and select the option that contains the output of the build Id. It should look something like this: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Firefox/38.0 ID:20150330004006 CSet: 9e57e9776571".
- Additional Builds and Platforms: Whether or not the bug takes place on other platforms (or browsers, if applicable). It should look something like this: "Doesn't Occur On Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Firefox/38.0 ID:20150330004006 CSet: 9e57e9776571".
- Steps to Reproduce: Minimized, easy-to-follow steps that will trigger the bug. If they're necessary, make sure to include any special setup steps. A good example of this would look like the following:
1) View any web page. (I used the default sample page, https://www.google.com/).
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. An example would be: The application crashed.
- Expected Results: What the application should have done, were the bug not present. An example would be: The window should scroll downwards. Scrolled content should be selected. Or, at least, the application should not crash.
Original document information
- Author(s): Aakash Desai
- Date last modified: June 3, 2013 at 2:41 am PST