There's another bug in this program as well.

If I check the Hide checkbox, all the guests who haven't

RSVPd should disappear from the page, but they don't disappear.

Instead, they become highlighted as if they were confirmed.

No further changes happen when I check or uncheck this box.

Let's inspect one of these items to see what may be happening.

I'll refresh and inspect Tammy's list item in the elements tab.

Now I will check the hide box again.

And you can see there's a problem here.

All of the guests who were not marked responded have been

added the class of responded.

And they also should be getting an inline display property of

none to make them hide from the page.

But that's not happening, which you can see here.

And you can also confirm that by looking down at its display property right here.

It's still list-item.

Setting an event listener breakpoint worked really well before,

so let's do it again here.

I'll go to the sources tab.

Set the breakpoint.

And it looks like it's already set from before, so

I'll leave the change event checked.

Now, I'll refresh and check the hide box.

The debugger's paused where the listener begins on line 17.

Before we start stepping through the program,

I'm immediately curious about what's happening in this for loop down here.

And that's because that's where the list items are being manipulated in our code.

We can jump to a specific line of code by setting a breakpoint.

While we previously set breakpoints on browser events,

this time we'll set one on a line.

To set a breakpoint click the line number where you want to break at.

Let's put our breakpoint on the line right after line 22 where

the list item is set up in the loop.

So line 23.

We can do this by clicking on 23 and to remove a breakpoint,

I'll just click it again.

And I'll put it back.

Now any time the JavaScript interpreter reaches this point,

it will pause right here.

You don't need to step through each line of code from 17 down to 23 either.

The play button right here and pauses the interpreter letting it run until

it reaches a breakpoint or the end of the program.

I'll press the play button now, see how it jump down there?

Now we're inside the first time through the loop.

You can tell because i is set to 0.

Also, if we hover over the li element in the scope window,

you can see the first name highlighted on the page.

Because our bug only affects unchecked guests, though, we might want to jump

ahead until we get to the fourth guest to see what is happening.

If I press play again, the loop will cycle around and land on the breakpoint.

Now i: 1 and li points to the second list item.

I'll press play two more times, and now we've landed on our unchecked guest.

Let's say we had a list of 200 guests though and

our bug only showed up at number 175.

That would mean we'd need to press the play button 175 times.

Fortunately, dev tools also lets us set a breakpoint

that will only pause if a certain condition is met.

Let's refresh this page and I'll show you how it works.

I'll go ahead and check the box to pause the execution at the top of our handler.

I'll click this breakpoint off.

Then I'll right-click line 23 and choose Add conditional breakpoint.

I can enter any condition here like

lI.classname is not equal to responded.

Now when I hit play, the loop won't stop until we get to the first

lI element without a responded class.

I'll hit enter to set our breakpoint, and now I'll hit play.

And we can verify it worked by hovering over the value and

you can see the fourth li is highlighted.

Now let me just show you one thing.

If I edit the breakpoint, we could've added any expression in here.

The same thing would've happened if we'd used i is strictly equal to 3,

for example.

If possible, though, it's better to pick an expression that gets you directly to

the situation you're diagnosing.

In this case, it's when an element is missing a certain class name.

I'll step forward now and

we'll expect to jump into the else clause of this if statement.

That's because the current list item's class name is not responded.

But the first branch is executing.

Moreover, the style of the element has changed and over in scope,

I can see that the class of responded has been added.

Can you spot the bug?

The single equal sign is an assignment operator.

It assigns the class to that element.

But it should be testing the condition using an equality operator.

So this should be three equal signs and not just one.

If you're wondering why three and not two, see the teacher's notes for

a more detailed discussion of the two operators.

I'll refresh, switch over to my editor.

And on line 23, I'll add the two more equals signs and save and

I'll switch back.

And now I'll disable all my breakpoints so

I can see if it's fixed or not and I'll check the hide box.

I need to refresh.

Now I'll check the hide box.

And you can see it works.

Let's review what we learned in this video.

We looked at two kinds of break points you can set on lines of your program.

A line breakpoint, and a conditional line breakpoint.

You'll probably use these a lot in your debugging process because they're so

versatile.

In the next video I'll show you how to debug functions.