How to find relevant code

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, 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:

Open Page Inspector, and inspect the button (If it's not page content but browser UI, you can use Browser Toolbox instead).

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:

You can search through source code in DXR or searchfox.

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 savedLogins.label name.

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 button with id="showPasswords".

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 privacy.js.

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

needs content

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.

needs content

Document Tags and Contributors

 Contributors to this page: arai
 Last updated by: arai,