this page is under construction
When you're going to work on a bug for a software first time, it would be a tough step to figure out where the code that needs fix is. Here's some hints for finding relevant code with various ways.
From changesets of already fixed bugs
Similar bugs should have been fixed by touching similar files. Looking into history will tell you relevant file and code.
If the bug is filed in bugzilla.mozilla.org, the bug should have "Component" field.
You can search for already fixed bugs in the component in Advanced Search, with the following query
- Product/Component - same as the bug
- Status - RESOLVED and VERIFIED
- Resolution - FIXED
It would be nice to specify the date, so that you can get the list of recent changes. There's "between" field, and there you can specify "-60d" that means "60 days ago".
In each bug that's fixed, there should be a comment that links to changeset. If the patch is applied to mozilla-central repository, it should be a link to
In the changeset's page, there's a list of modified files, and diff.
With Developer Tools
If you're going to work on a bug that is displayed as web content, you can use Developer Tools to investigate the implementation.
For example, suppose you're going to fix the behavior of the following "Saved Logins…" button in Firefox:
there, you'll see "ev" label next to the tag.
By clicing it, you can see the code of the event handler associated to the event.
Also, by clicking the icon before the event name ("command" for this case), you can open it in Debugger.
From UI label or message
If you're going to work on a bug that has UI part, you can look for relevant code by searching UI label.
Example - DTD
For example, again, suppose you're going to fix the behavior of the following "Saved Logins…" button in Firefox:
In most case, UI label and messages are stored in dedicated file for localization, like DTD (*link here) or
.properties (*link here). So if you're going to touch underlying implementation, the next step is to find a place that refers the definition.
In this case, it's stored in
security.dtd file, defined with
if it's defined in DTD, it's refered with
&name; syntax (
&savedLogins.label; for this case).
In this case, it's referred from
security.xul. It's a label of a
But there is not underlying implementation for the button here. Its event handler should be added from another place. In that case, you can look for the code by the button's id.
So, there's a code that looks like setting event listener in
The event handler is defined as
gPrivacyPane.showPasswords. The definition should be searchable by "
showPasswords =" ( property assignment) or "
showPasswords:" (property item) or "
showPasswords(" (method definition).
In this case, it's in method definition style.
Example - properties file
With external debugger
If you're going to fix crash bug or similar thing, running the application on debugger should be an easy way to figure out the relevant code.