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: https://codepen.io/mherchel/pen/ajYGKz 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: https://www.chromium.org/getting-involved/dev-channel. Thanks!
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?
Aug 3, Project Member
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
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