Firefox JavaScript Debugger: Conditional Breakpoints, Logpoints, XHR Breakpoints, Blackboxing, and Source Maps

The JavaScript Debugger is the most underused part of Firefox's DevTools. Many developers rely on console.log() to debug, but the debugger is often faster and reveals more. Firefox's debugger has some features that make it particularly powerful for complex JavaScript applications: source maps, Blackboxing, conditional breakpoints, and XHR breakpoints.

Opening the Debugger

• F12 → Debugger
• Ctrl+Shift+S opens DevTools directly to the Debugger
• Click any file/line link in a console error stack trace

Basic Breakpoints

Click any line number in the source panel to add a breakpoint. A breakpoint pauses execution at that line.

While paused:

• Step Over (F10): execute current line, go to next
• Step Into (F11): enter function call on current line
• Step Out (Shift+F11): finish current function, return to caller
• Continue (F8): resume execution until next breakpoint
• Resume and Step (not in toolbar — press F8 then F10 quickly): continue one statement

The Call Stack panel shows the current execution context — all function calls that led to the current line.

The Scopes panel shows variables in scope: local, closure, and global. Expand any object to inspect its properties without touching the console.

Conditional Breakpoints

Right-click any line number → Add Conditional Breakpoint → enter a JavaScript expression.

user.role === 'admin'

The breakpoint only triggers when the condition is true. Essential for debugging issues that only appear for specific data:

• Loop iterations: i === 47 (break only on the 48th iteration)
• API response: response.status !== 200
• Specific user: user.id === 'problematic-user-id'

Without conditional breakpoints, you'd have to click Continue hundreds of times or instrument the code with if-statements.

Logpoints

Right-click any line → Add Log Point → enter an expression to log.

`Rendering item ${item.id} with ${item.children.length} children`

This is like a console.log() without modifying the source code. The log appears in the console with a marker showing which logpoint it came from.

Logpoints are useful when you want console.log behavior but:

• Can't modify the code (minified, third-party)
• Don't want to remember to remove logs before committing
• Want to log from multiple places quickly

XHR/Fetch Breakpoints

In the Breakpoints panel (right side) → XHR/fetch Breakpoints → click +.

Enter a URL substring. The debugger pauses when any XHR or fetch request matches that URL.

/api/users

This pauses execution at the point in your code that initiated the request — showing you the call stack of what triggered the API call. Useful for:

• Finding which code is making unexpected API calls
• Debugging race conditions in request timing
• Tracing which user action triggers a specific API call

DOM Mutation Breakpoints

Right-click any DOM element in the Inspector → Break on... → choose:

• Subtree Modifications
• Attribute Modifications
• Node Removal

The debugger pauses when JavaScript modifies that DOM node. Useful for finding what code is unexpectedly changing a DOM element — the call stack reveals the culprit.

Exception Breakpoints

Click the exception icon in the debugger toolbar (or hover → "Pause on exceptions"). Options:

• Pause on all exceptions (including caught ones)
• Pause only on uncaught exceptions

With this enabled, any thrown error immediately pauses the debugger at the throw site — before it reaches any catch handler. You see the actual state at the moment the error occurred.

Blackboxing (Ignore List)

When stepping through code that calls React, jQuery, or other libraries, you'll step into those libraries repeatedly — irrelevant for debugging your own code.

Right-click any library file in the source list → Add to Ignore List.

Firefox will "step through" that file without pausing. The debugger skips to the next non-ignored frame. This makes React/Redux debugging much faster — you only see your own code.

You can also blackbox by URL pattern: DevTools Settings → Debugger → Framework Grouping, or manually add patterns to the ignore list.

Source Maps

Firefox automatically resolves source maps for minified code. If a .js.map file is linked in the minified file's last comment:

//# sourceMappingURL=bundle.js.map

The Debugger shows the original source code instead of the minified bundle. Set breakpoints in the original TypeScript/JSX files.

For inline source maps (base64-encoded map in the file), Firefox handles these too.

Webpack development server: if you're running webpack-dev-server with devtool: 'source-map' or devtool: 'eval-source-map', Firefox shows your original files in the debugger.

Search Across All Sources

Ctrl+Shift+F in the Debugger panel — search across all loaded JavaScript files. Type a function name, variable, or string literal. Firefox finds every occurrence in every loaded script.

Useful when you don't know which file contains a specific function or when you're exploring unfamiliar code.

Pretty Print

Minified code is hard to read even with source maps. The {} button (Pretty Print Source) in the Debugger formats the current minified file with indentation and line breaks. This is a fallback when source maps aren't available.

Watch Expressions

In the Watch panel (right side), add expressions to evaluate whenever the debugger pauses:

• user.authentication.token.length
• Date.now() - startTime
• window.innerWidth

These are re-evaluated at every pause, showing current values without having to type them in the console each time.

Async Stack Traces

For debugging async/await code, Firefox shows the async call stack — not just the current synchronous stack, but the chain of promises that led to the current execution point.

In the Call Stack panel, look for "Async" sections showing the async function that created the promise chain leading to the current code. This is invaluable for tracing which await triggered a specific callback.