Debugging in the browser

Debugging means pausing your code

A bug is a mistake in a program. Because of it, the program does something you did not expect. Debugging means finding that mistake and fixing it.

The browser has a tool for this, called the debugger. It can pause your JavaScript while it runs. While the code is paused, you can:

• see which line runs next,
• move forward one line at a time,
• look at the values your variables hold right now.

In earlier lessons you used DevTools, the developer tools built into the browser. You used its console and console.log to print clues. Printing is still useful. But the program keeps running while it prints. The debugger is different. It stops the program, so you can look around before anything else changes.

To find the debugger, open DevTools and pick the right panel:

• In Chrome and Edge, open the Sources panel.
• In Firefox, open the Debugger panel.
• In Safari, first turn on the developer features in Safari's settings. Then open the Sources panel.

The names are different in each browser. The ideas in this lesson are the same in all of them.

A breakpoint is a marker you put on a line of code. When JavaScript reaches that line, the browser pauses before it runs the line. To set one in most browsers, open your file in the debugger panel and click the line number.

1const cart = { total: 20 };2cart.total = cart.total + 5;3console.log(cart.total);

Line 1 makes a cart object with a total of 20. Line 2 adds 5 to the total. Line 3 prints the total.

Put a breakpoint on line 2. The browser pauses before line 2 runs. The Scope panel lists your variables and the values they hold right now. It shows cart.total as 20. Now press Step over, the button that runs one line. Line 2 runs, and cart.total is now 25. Then line 3 prints 25.

This is the main question a debugger answers: what value did a line get, and what did it change?

The debugger has several kinds of breakpoints:

• Line breakpoint: pauses every time one line runs.
• Conditional breakpoint: pauses only when a test you write is true. For example, i === 50 inside a loop.
• Logpoint: prints a message when a line runs. It does not pause, and it does not change your file.
• Pause on exceptions: pauses on the line where an error is thrown. An exception is another word for a thrown error. Many browsers can also pause on errors that your code catches with try/catch.
• DOM and event listener breakpoints: pause when part of the page changes, or when an event such as a click happens. The DOM is the browser's model of the page. These are browser features. They are not new JavaScript code.

1// Line breakpoint: pause whenever this line runs.2total = total + price;3 4// Conditional breakpoint: pause only when this is true.5i === 506 7// Logpoint: print a message without pausing.8"total is", total9 10// Pause on exceptions: stop where an error is thrown.11throw new TypeError("price must be a number");

This block is not one program to run. Each comment names one kind of breakpoint, and the line under it shows where it goes. In plain words, line by line:

1. Line 2 is a line to pause on, with a line breakpoint.
2. Line 5 is the test you type for a conditional breakpoint.
3. Line 8 is the message you type for a logpoint.
4. Line 11 throws an error. Pause on exceptions would stop on this line.

The table below compares four of these tools. Read each row as: "I use this tool when…, and then this happens."

Conditional breakpoints help a lot in loops. Say a list has 100 items, and only item 50 is wrong. A normal breakpoint would pause 50 times before you reach it. A test such as i === 50 lets the browser skip straight to the item you care about.

1const score = 42;2console.log(score === 42);

Line 1 stores 42 in score. Line 2 prints the result of score === 42, which is true. So a conditional breakpoint with the test score === 42 would pause here. If you change the score to 41, the test gives false, and the browser keeps running. The test only reads values. It does not change them.

JavaScript has a built-in statement called debugger. A statement is one instruction in your code. When DevTools is open, the browser pauses on the debugger; line, just like at a breakpoint. When DevTools is closed, browsers usually ignore it and keep running.

It helps in two cases:

• You can't easily find your file in the debugger panel. Tools that pack your code into one big file can make this hard.
• You want a quick pause in a small test on your own computer.

It is also easy to forget. Remove debugger; before you share your code.

1function saveTodo(todo) {2  debugger;3  console.log(todo + " saved");4}5 6saveTodo("tea");

Line 2 pauses the code, but only for someone who has DevTools open. Press Resume, the button that lets the code keep running. Then line 3 prints tea saved. This is handy for a quick check. In code you share, a line breakpoint is usually better, because it leaves nothing behind in the file.

1function handleDebugClick() {2  const label = "Debug button";3  debugger;4  console.log(label + " finished");5}6 7document.querySelector("button").addEventListener("click", handleDebugClick);

When the code is paused, the debugger's toolbar has buttons that move it forward. In Chrome and Edge, they are:

• Resume (F8): keep running until the next breakpoint.
• Step over (F10): run the current line, then pause on the next one.
• Step into (F11): if the line calls a function, go inside that function and pause on its first line.
• Step out (Shift + F11): finish the function you are in, then pause on the line that called it.

Other browsers have the same buttons, but the keys can be different.

1totalCart(items);          // Step into opens totalCart2applyDiscount(total);    // Step over runs it and stays here3return roundPrice(value); // Step out finishes this function

This block is not one program to run. Each line shows one call, and its comment names a button. In plain words:

1. Step into goes inside totalCart, so you can read its lines.
2. Step over runs applyDiscount and pauses on the next line, without going inside.
3. Step out finishes the function you are in, and goes back to the line that called it.

1function addTax(price) {2  return price + 2;3}4 5const total = addTax(5);6console.log(total);

Lines 1 to 3 make a function, addTax, that adds 2 to a price. Line 5 calls addTax(5) and stores the result in total. Line 6 prints it.

Pause on line 5. Then:

• Step over runs addTax(5) without showing its lines. It stores 7 in total and pauses on line 6.
• Step into goes inside addTax first, and pauses on line 2.

Both ways print the same result: 7. The button changes only what you see. It does not change what the code does.

The next replay runs one program that has a bug. A cart holds two prices, 20 and 10, so the total is 30. The program should take 10 percent off once. That gives 27. But the bug takes 10 percent off twice. Pick Step into or Step over. Both show the same wrong result: 24.3.

1const items = [20, 10];Run2 3function roundPrice(amount) {4  return Math.round(amount * 100) / 100;5}6 7function applyDiscount(amount) {8  const discounted = amount * 0.9;9  return roundPrice(discounted);10}11 12function totalCart(prices) {13  let total = 0;14  for (const price of prices) {15    total = total + price;16  }17  const firstPass = applyDiscount(total);18  const finalTotal = applyDiscount(firstPass);19  return finalTotal;20}21 22console.log(totalCart(items));

The bug is on line 18: applyDiscount(firstPass). Step into shows it clearly. Inside the second call to applyDiscount, you can see that amount is already 27. With Step over, the function still runs, but you see only the value it gives back, not its lines.

Step out helps when you are already inside a function. For example, if you are inside roundPrice, Step out finishes roundPrice and takes you back to applyDiscount, the function that called it.

When the code is paused, the debugger shows what each name holds at that moment. The Scope panel lists the variables your code can reach right now. It puts them in groups:

• Local: variables inside the function that is running now.
• Closure: variables from an outer function that the current function still remembers. The Closures lesson explains this later.
• Global or Script: variables made at the top level of the page or script, outside any function.

One detail: a top-level let does not become a property of window, the object that stands for the browser window. DevTools may still list it under Script.

An expression is a piece of code that gives a value, like 2 + 3. A Watch expression is an expression you pin to the debugger, like a gauge on a car's dashboard. Each time the code pauses, the browser works out its value again from the current values. Good watches are small, like subtotal * discountRate, items.length, or total === 27.

1const subtotal = 30;2const discountRate = 0.1;3console.log(subtotal * discountRate);

Line 1 stores a subtotal of 30. Line 2 stores a discount rate of 0.1, which means 10 percent. Line 3 prints subtotal * discountRate, which is 3.

Pause after line 2 and pin subtotal * discountRate in Watch. It shows 3, the same as the console. This watch only reads values, so it is safe to work out again and again. A watch such as cart.add() is different. It would add to the cart every time DevTools works it out.

Start with one small calculation. In the replay, pause inside calculateTotal to see its Local values. When the function finishes, its Local values are gone. The top-level total stays.

1function calculateTotal(amount, discountRate) {2  const discount = amount * discountRate;3  return amount - discount;4}5 6const subtotal = 30;Run7const discountRate = 0.1;8const total = calculateTotal(subtotal, discountRate);9console.log(total);

Line 2 makes the Local value discount. A Watch for amount * discountRate would show 3 at that pause. Line 8 stores the 27 that the function gives back in total, at the top level of the script. That is why the next pause no longer shows the function's Local values.

1const subtotal = 30;2const discountRate = 0.1;3 4function applyDiscount(amount) {5  const discounted = amount - amount * discountRate;6  return Math.round(discounted * 100) / 100;7}8 9const total = applyDiscount(subtotal);

Debugging is faster when you pick the smallest tool that answers your question. First, here is what to do each time the code pauses.

Now sort each case below by the kind of tool you would use first.

Where you will use this

The debugger helps most when the code looks right, but the values are wrong. A shopping cart, a form check, a quiz score, or a button can all go wrong because one value changed earlier than you thought.

1const form = { email: "" };2const canSubmit = form.email !== "";3console.log(canSubmit);

Line 1 makes a form with an empty email. Line 2 sets canSubmit to true only if the email is not empty. Line 3 prints the result.

Say the form's Submit button won't work. Put a breakpoint on line 2 instead of guessing. Scope shows form.email as an empty string, "". So canSubmit becomes false, and line 3 prints false.

Here is the full cart program from the replay again. Lines 17 and 18 are highlighted. Try the routine below on it.

1const items = [20, 10];2 3function roundPrice(amount) {4  return Math.round(amount * 100) / 100;5}6 7function applyDiscount(amount) {8  const discounted = amount * 0.9;9  return roundPrice(discounted);10}11 12function totalCart(prices) {13  let total = 0;14  for (const price of prices) {15    total = total + price;16  }17  const firstPass = applyDiscount(total);18  const finalTotal = applyDiscount(firstPass);19  return finalTotal;20}21 22console.log(totalCart(items));

A good debugging routine has five steps:

1. Say what goes wrong, in one sentence.
2. Set a breakpoint just before the value first looks wrong.
3. Step over functions you trust. Step into functions that might hide the bug.
4. Read Scope before you guess. Add a Watch for any value you keep working out by hand.
5. Fix the smallest line you can. Then run the program again from the start.

Common mix-ups

Each row of the table below compares two tools that are easy to mix up. Read it as: "Use the first tool when…, and the second tool when…"

Try each exercise before you open the hints. Some ask what a value would be at a pause. Others ask you to use the real debugger in your own browser.

function double(number) {
  const result = number * 2;
  return result;
}
console.log(double(6));

i === 50

function checkForm() {
  debugger;
  return true;
}

const subtotal = 30;
const discountRate = 0.1;
const total = subtotal - subtotal * discountRate;
console.log(total);

const firstPass = applyDiscount(total);
return firstPass;

Pick an answer and read why it is right or wrong. Then think about which DevTools button or panel you would use.

Key takeaways

• A breakpoint pauses the code, so you can see the exact moment a value changes.
• debugger; pauses the code when DevTools is open. Remove it when you are done.
• Step over runs a function call without going inside. Step into goes inside. Step out finishes the current function.
• Scope shows the values your code can reach right now. Watch shows the expressions you pinned, worked out again at every pause.
• The course replay helps you learn. Your browser's DevTools debugs real code.

Up next: Coding style & naming.