User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:104.0) Gecko/20100101 Firefox/104.0

Steps to reproduce:

1. Navigate to data:text/html;charset=utf-8,<h1>foo</h1><span>bar</span>

2. Open Devtools

3. In the inspector, right click the span element, select "Break On" and select "Subtree Modification."

(The mutation type and html element do not matter.)

4. Refresh browser.

Actual results:

The Dom Mutation Breakpoint icon is gone, the subtree markup-context-menu item is not checked.

Switch to debugger. The breakpoint is still listed in DMB pane, but disabling/enabling and or removing does not work.

Expected results:

The Dom Mutation Breakpoint icon should still be visible in the inspector, the subtree context menu item should still be checked, and the breakpoint in the debugger DMB pane should be able to be toggled or removed.

The Bugbug bot thinks this bug should belong to the 'DevTools::Inspector' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Thanks for filing.

The Dom Mutation Breakpoint icon should still be visible in the inspector, the subtree context menu item should still be checked, and the breakpoint in the debugger DMB pane should be able to be toggled or removed.

We could try to restore breakpoints by xpath, but there is no guarantee that an element at a given xpath will be available after a reload, or that it will be semantically the same element. So doing this sounds fragile.

I think a more reasonable approach here would be to cleanup the debugger state and remove the breakpoints.

For the record, I can see that Chrome DevTools attempt to restore breakpoints, but their DOM breakpoints UI seems quite buggy (after a reload, the DOM breakpoints get duplicated in the Sources panel) so I'm not sure we should use this as reference.

Edit: And they restore by xpath apparently, so the element on which the DOM breakpoints are re-added after reload might have nothing to do with the existing one. And they don't only restore on reload, they seem to keep track of DOM Breakpoints per URL. So if you go to mozilla.org, set a DOM breakpoint, go to wikipedia.org and go back to mozilla.org, the DOM breakpoint will be restored (again by xpath, so not necessarily on the element where it was "initially" added)

Discussing with the team, restoring DOM breakpoints sounds useful and we should try to do it. Will file another bug to clear the debugger state for now, let's keep this one for the requested enhancement.