New issue
Advanced search Search tips
Starred by 1 user

Issue metadata

Status: WontFix
Closed: Sep 28
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

Sign in to add a comment

Issue 869986: DOM Breakpoints not working on page reload

Reported by, Aug 1

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36

Steps to reproduce the problem:
1. Create HTML element that is modified by JavaScript on page load. 
2. Within DevTools, create a DOM breakpoint by right clicking on this element, and selecting the option for "Break On" and then select "Subtree modifications" (or whatever's being modified.
3. Reload the page. Note that the breakpoint does not catch. Also note that the breakpoint DOES exist on the sources panel under the DOM breakpoints area.

What is the expected behavior?
I expected the breakpoint to catch when the page was reloaded, but before the element was modified.

What went wrong?
The breakpoint didn't catch. 

Did this work before? N/A 

Chrome version: 67.0.3396.99  Channel: stable
OS Version: OS X 10.13.6
Flash Version: 

I created a demonstration of this behavior at

Comment 1 by, Aug 2

Labels: Needs-Triage-M67

Comment 2 by, Aug 3

Labels: Needs-Feedback Triaged-ET
Unable to reproduce the issue on chrome reported version# 67.0.3396.99 using Mac 10.12.6 with steps mentioned below:
1) Launched chrome reported version and navigated to URL:
2) Opened Devtools and on elements tab created DOM Breakpoint by right clicking > Break On > Subtree modifications
3) Reloaded the page, observed DOM Breakpoint on the Elements tab

@Reporter: Please find the attached screencast for your reference and let us know if we missed anything in reproducing the issue, provide your feedback on it which help in further triaging it. Try to test this issue by creating new person with no apps and extensions in it or test the issue on latest chrome stable# 68.0.3340.84, you can download latest chrome stable from URL:

2.2 MB View Download

Comment 3 by, Aug 3

Yes, you're seeing the same behavior I am. 

But, I am expecting the breakpoint to break *before* the "Text modified" text gets inserted, and then be taken to the sources panel.

Does this make sense?

Comment 4 by, Aug 3

Project Member
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit - Your friendly Sheriffbot

Comment 5 by, Aug 13

Status: Assigned (was: Unconfirmed)

Comment 6 by, Sep 28

Status: WontFix (was: Assigned)
Thanks for your report!

DOM modification breakpoint uses reference to node to set breakpoint. After reload we have new node and we do not have a way to match new node with old one so we do not support dom breakpoints on reload.
UI in ToT Chrome does not show dom breakpoint after reload. So it works as intended.

We can resolve it by storing dom breakpoint by CSS selector but this work requires big dom breakpoint rework that unfortunately we can not afford right now.

Sign in to add a comment