cloud9342.cfd

Troubleshooting with Git History for Firefox: Find Who Changed What

Written by

admin

in

Why Git history matters for debugging Firefox

  • Authors and context. A commit often includes a description, bug number, and a patch link. That metadata helps you understand why a change was made and whether it was intentional or experimental.
  • Binary regressions and blame. Finding the exact commit that introduced a regression (a “regression range”) is often faster than guessing from symptoms alone.
  • Reverts and patches. Mozilla’s process typically includes reverts, follow-ups, and test additions; reading the chain of commits often reveals intended behavior and what subsequent fixes addressed.
  • Collaboration. Identifying the right person to ask (author, reviewer, or a module owner) speeds resolution.

Preparation: set up your environment

  1. Clone the relevant repository. Firefox development is split across several repositories; for browser code you’ll typically work in mozilla-central:

    git clone https://github.com/mozilla/gecko-dev.git cd gecko-dev

    (Alternate remotes: Mozilla’s Mercurial mirrors/archives exist historically; many contributors use hg.mozilla.org mirrors — but gecko-dev on GitHub is the standard public Git mirror.)

  2. Configure Git for useful output:

    git config --global user.name "Your Name" git config --global user.email [email protected] git config --global pager.log true

  3. Fetch all branches and tags to ensure you have history:

    git fetch --all --tags --prune

Tools you’ll use

  • git command line (log, blame, bisect, show, grep)
  • Searchfox (searchfox.org) — fast code search and cross-references for mozilla-central
  • MozReview/Phabricator (historical) and GitHub Pull Requests/Review workflow (current)
  • Bugzilla (bugzilla.mozilla.org) — bug reports often referenced by commit messages
  • Treeherder and Taskcluster — CI and test results tied to pushes
  • Local IDE/editor with Git integration for quick diffs and blame views

Step-by-step troubleshooting workflow

1) Reproduce and isolate

Before diving into history, reproduce the bug locally and identify the smallest reproducible steps. Note platform, channel, build configuration, and whether Safe Mode or extensions affect it.

2) Narrow the scope of code

Use stack traces, crash reports, or UI clues to identify components (e.g., networking, rendering, WebExtensions). Searchfox and code search help locate relevant files and functions.

Example Searchfox search:

  • Search for function names seen in a stack trace
  • Search for recently changed files in a directory: use Searchfox’s “commits affecting this file” link

3) Use git log and grep to find likely commits

Look for recent commits that touch suspect files or mention related keywords (bug numbers, feature names, regression indicators).

git log --pretty=oneline --abbrev-commit -- <path/to/file> git log --grep="regression" --since="3 months ago"

Commit messages often include “bug XXXX” where XXXX is a Bugzilla ID — follow that link.

4) Identify who changed what: git blame and git annotate

When a specific line or block appears incorrect, use git blame to see the commit and author that last modified it.

git blame -L <start>,<end> -- <file>
  • The output shows commit hashes and authors per line.
  • Use git show <hash> to view the full commit message, diff, and linked Bugzilla URL.

Tip: For generated files or large refactorings, blame can be noisy; use -w to ignore whitespace-only changes:

git blame -w -- <file>

5) Find regressions with git bisect

If you know a revision range where the bug appeared (e.g., it worked in version N and broke in version N+1), use git bisect to find the exact commit introducing the change.

git bisect start git bisect bad           # current bad revision (where bug appears) git bisect good vX.Y.Z   # known good revision # follow prompts: run tests or reproduce; then mark bad/good until bisection completes git bisect reset

Automate bisect with a script that returns exit status 0 for good and 1 for bad to speed up large histories.

Once you find a suspect commit, inspect it:

git show --stat --patch <commit>
  • Look for referenced bug numbers, reviewers, and test changes.
  • Use git log --ancestry-path <good>.. <bad> to see commits in a path between revisions.
  • Check parents and children (use GitHub/Treeherder for push-to-central history) to find follow-up fixes or reverts.

7) Use Bugzilla and code-review context

Open the Bugzilla bug mentioned in the commit. Read discussion, attachments (patches), review comments, and regression testing. Many bugs include testcases or a STR (steps to reproduce). If a review was hesitant or noted edge cases, that context can explain why a change regressed something.

8) Inspect CI and test results (Treeherder/Taskcluster)

Treeherder ties pushes to test failures. Find the push that introduced the commit and inspect failing tests and logs. Taskcluster artifacts can include builds and crash reports.

9) Communicate with the right people

If the commit is legitimate but buggy, identify the author, reviewer, module owner, or people subscribed to the bug. Bugzilla threads and commit messages usually list reviewers and r+ approvals. Be concise in messages: reproduction steps, minimal test case, suspected commits, and suggested fixes.

Practical examples

Example A — Simple UI regression

  • Symptom: Toolbar button stops responding after recent update.
  • Steps:
    1. Reproduce and find relevant file (e.g., browser/components/toolbar/Toolbar.jsm).
    2. Use git log -- <file> to view recent changes.
    3. Use git blame on the handler function to find the commit and author.
    4. Open the referenced Bugzilla bug for context.
    5. If uncertain, bisect between a known working nightly and current build.

Example B — Rendering regression found via crash

  • Symptom: Crash in compositor thread after a nightly push.
  • Steps:
    1. Find crash signature and stack trace in Socorro/crash-stats.
    2. Search stack functions in Searchfox to find files.
    3. Use git log and Treeherder to identify the push that introduced the change.
    4. Use git show on suspect commits and inspect tests added/changed.
    5. Reproduce with a debug build and confirm fix or revert as needed.

Reading commit metadata effectively

  • Commit messages commonly include lines like “Bug 123456 — Fix rendering of X”. The bug number is your primary breadcrumb.
  • Look for “r=someone” or “sr=someone” to find reviewers and super-reviewers.
  • “Backed out” messages and reverts often include a reason and link to the backing-out bug.

When blame is noisy or unhelpful

  • Large refactors or formatting-only commits make git blame noisy. Use:
    • git blame -w to ignore whitespace changes.
    • git log -S'snippet' -- <file> to find when a code snippet was introduced.
    • gitk --follow <file> or Searchfox’s history view for file renames.

Creating a minimal test and patch

  1. Reduce the problem to a small testcase (HTML/CSS/JS or mochitest) that reproduces the issue.
  2. Attach the testcase to the Bugzilla bug and reference the offending commit.
  3. Create a local branch, implement a fix or revert, and run tests locally.
  4. Push a patch for review with clear motivation, STR, and tests. Use Mozillians’ review conventions in commit message: include Bugzilla ID, tests added, and requested reviewers.

Example commit message skeleton:

Bug 123456 — Fix toolbar handler to call event.preventDefault in X case. - Add mochitest to cover regression - r=reviewer, a=author

Best practices and etiquette

  • Don’t assume malice — many regressions come from subtle API changes or missed edge cases.
  • Provide reproduction, exact builds, platform, and steps. This saves hours for maintainers.
  • When asking authors, be polite and concise: link to commits/bugs and include minimal repro.
  • If you propose a revert, verify tests and side-effects; reverts often require follow-up fixes.

Quick cheatsheet (commands)

  • View commits touching a file: 
    
git log --pretty=oneline -- <path>
  • Find commit for a line: 
    
git blame -L <start>,<end> -- <file>
  • Inspect a commit: 
    
git show --stat --patch <hash>
  • Bisect to find regression: 
    
git bisect start git bisect bad git bisect good <revision>
  • Search commit messages: 
    
git log --grep="Bug 123" --since="2 months ago"

Closing notes

Finding “who changed what” in Firefox requires combining Git skills with the Mozilla ecosystem: Bugzilla for discussion, Searchfox for code navigation, Treeherder for CI context, and clear communication with authors and reviewers. Mastering git blame, bisect, and commit inspection—plus knowing where to look for review context—turns a frustrating regression hunt into a systematic diagnostic process.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts