Find UI bugs with Event Listener Breakpoints

Table of Contents

1. Challenge

   Step 1: Explore the App

   warning> This lab requires Chrome or a Chromium-based browser. The Event Listener Breakpoints panel is specific to Chrome DevTools and will not appear in other browsers.

   When a UI element stops responding and the console shows nothing, the bug can feel invisible. Chrome DevTools Event Listener Breakpoints give you a way to intercept any DOM event the instant it fires, pausing JavaScript execution so you can inspect the exact state of the handler before anything goes wrong.

   A teammate reported that clicking a Mark Done button does not always complete the task. To begin, you'll start the local server and open the app in Chrome to reproduce the broken behavior firsthand.

   If you get stuck, the solution folder has a working implementation you can reference. Give it a try on your own first, but it's there as a safety net if you need it. warning> Clicking the link below will open the app in a new browser tab. After you open that tab and confirm the broken button, return to this tab to continue with the next steps.

   Open the app at {{localhost:3000}} in Chrome.

   Click the Mark Done button on any task. The button does not consistently mark the task as done.

   Because the page does not show an obvious error, you need a targeted way to inspect what happens when the click event fires. info> This lab experience was developed by the Pluralsight team using an internally developed AI tool. All sections were verified by human experts for accuracy prior to publication. However, content may still contain errors or inaccuracies, and we recommend independent verification.
   
   To report a problem or provide feedback, click here. Feedback may be used to improve accuracy in accordance with our Privacy Policy.

2. Challenge

   Step 2: Open Event Listener Breakpoints

   The task tracker is running at {{localhost:3000}}.

   You could add console.log statements to app.js, but that requires guessing where to inspect the code. Instead, you'll use Chrome DevTools to pause JavaScript execution as soon as a click event fires.

   Hint

   Clicking the text inside a Mark Done button does nothing, but clicking the padding around that text works. That difference is a clue that the click handler may receive different event details depending on where inside the button you click.

   Enable the click breakpoint

   Switch to the app browser tab, then open Chrome DevTools:

   • On Windows or Linux, press F12.
   • On macOS, press Cmd+Option+I.

   You'll see several panels in the Sources tab. The main panel in the center is where source files appear when you open them. The left panel shows a file navigator, and the right panel contains debugging tools.

   In DevTools:

   1. Select the Sources tab.
   2. In the debugging panel (the right panel), expand Event Listener Breakpoints.
   3. Expand Mouse.
   4. Select click.

   The breakpoint is now active. Chrome will pause execution the next time a click event fires on the page.

   Next, you'll trigger the breakpoint.

   Trigger the breakpoint

   In the app, click directly on the Mark Done text inside one of the buttons.

   Chrome pauses in app.js on the statement that reads the task ID from the click event:

   let taskId = event.target.dataset.taskId;
   

   At this point, the app is paused before the handler finishes running. Next, you'll inspect the values the handler is using.

3. Challenge

   Step 3: Trace the Call Stack

   With the Mouse > click breakpoint enabled, you can inspect the click handler while it runs. This helps you find out why the button does not always update the task.

   Inspect the task ID

   Click the Step over button, or press F10, to execute the task ID assignment and move to the next line.

   The Step over button is in the small toolbar above where you set the Mouse > click breakpoint. It looks like an arrow curving over a dot.

   After stepping over, hover over the taskId variable in the source code. You'll see it shows undefined.

   That confirms the handler did not get a task ID. Because the handler does not know which task to update, the Mark Done button cannot complete the task.

   The task ID comes from the data-task-id attribute on the Mark Done button. When that attribute is missing from the element the handler is reading, taskId ends up undefined and the update does not happen.

   Trace why the attribute is missing

   To understand why the attribute is missing, inspect the event object:

   1. Find the Scope section above the Event Listener Breakpoints section.
   2. Expand the local scope.
   3. Find event in the variable list, expand it.
   4. Scroll to target.

   The target value is a <span> element, not the <button> itself.

   That <span> has no data-task-id attribute, which is why taskId is undefined.

   To compare the event target with the button markup:

   1. Click the Resume button (or press F8) to unpause execution.
   2. Right-click on any Mark Done button in the app.
   3. Select Inspect.

   The Resume button is in the same toolbar as the Step over button. It looks like a right-pointing triangle, similar to a play button.

   The DevTools Elements panel opens and highlights the exact element you clicked. You'll see that the button contains a <span> with the label text, and that's the element event.target points to when you click the text.

   The structure is similar to this:

   <button data-task-id="1">
     <span>Mark Done</span>
   </button>
   

   Notice that the data-task-id attribute is on the <button> element itself, not on the <span>. That is why the handler can't find it.

   When you click directly on the Mark Done text, event.target points to the <span>. Because the <span> does not have a data-task-id attribute, this expression returns undefined:

   event.target.dataset.taskId
   

   Try clicking the button padding

   Now try clicking the padding area around the button text instead.

   When Chrome pauses again:

   1. Click Step over, or press F10.
   2. Hover over taskId.

   This time, taskId has a value.

   The difference is caused by the exact element that receives the click:

   • When you click the text, event.target is the inner <span>.
   • When you click the padding, event.target is the <button>.
   • The task ID exists on the <button>, so the handler only works when the button itself is the event target.

   You now have the information you need to fix the bug. The handler should not read the task ID from the deepest clicked element. It should read the task ID from the element that owns the event listener.

4. Challenge

   Step 4: Fix the Bug

   The DevTools trace revealed that event.target points to the <span> inside the button when the user clicks the label text. That span has no data-task-id attribute, so the task ID lookup returns undefined and the update never happens.

   Use event.currentTarget instead.

   The event object exposes two related properties:

   • event.target is the exact element that received the click.
   • event.currentTarget is the element that the event listener is attached to.

   In this app, the event listener is attached to the Mark Done button. That means event.currentTarget reliably points to the <button>, even when the user clicks the inner <span>.

   Next, you'll update app.js and reload the app to confirm the button works. You've traced a real DOM event bug from symptom to root cause and applied a targeted one-line fix.

   Using Chrome DevTools Event Listener Breakpoints, you paused execution the moment a click fired, inspected event.target in the Scope panel to see the misidentified inner element, and corrected the handler to use event.currentTarget, the reliable reference to the element the listener is registered on.

   This technique transfers directly to any event-driven UI bug: no console.log required, no source-code guesswork.