When a traditional breakpoint triggers a pause, we show a green line to the left of the breakpoint listing in Breakpoints panel.

Ideally we'd be able to do the same with DOM mutation breakpoints -- show a green left border to the left of the breakpoint that triggered the pause.

Presently our "why paused" logic provide the following information for DMBs:

{
message: "DOM Mutation: 'attributeModified'"
mutationType: "attributeModified"
type: "mutationBreakpoint"
}

Unfortunately that doesn't provide information about which node triggered the issue, so maybe we need a nodeFront added to this so we know which DMB to highlight.

This looks like a good idea, I like that.

@Harald?

Honza

Sure, nice affordance. A link from the why-paused panel to focus the breakpoint entry would also fit with this.

This is more difficult than I had hoped, unfortunately; the information we get in the Mutations panel is different than the Why information received when the server hits a DOM mutation breakpoint:

• WhyPaused: Gets actor: "server0.conn0.child1/obj62"

• DOM Mutation Breakpoints: actor: "server0.conn0.child1/domnode29"

@Logan: Is there a good way to reconcile this difference?

Just as guidance for this work: This is a "nice to have", so we want to make should make sure that we don't spend too much engineering time on this. The reason would be that we don't highlight the currently paused breakpoint entry for any other BP type atm.

Probably the thing to do would be to use https://searchfox.org/mozilla-central/rev/d7537a9cd2974efa45141d974e5fc7c727f1a78f/devtools/server/actors/inspector/walker.js#2618 to get the get the node actor for the object grip.

We do highlight standard breakpoints hit, but point taken.

Hi David Walsh, i'm interested in working with you on this issue. How can I get started?. Thank you

Hi @David. I've timeboxed a few hours on this and am having trouble with the pause event object grip to node actor conversion step.

I've tried using two client-side interfaces for getNodeActorFromObjectActor, which @Logan describes above. One of those interfaces exists as a method on walkerFronts, which are themselves properties on nodeFront, called gripToNodeFront. Here's that method:
https://searchfox.org/mozilla-central/rev/c2bc259414706ef4be5d13df1344eebb7507a51b/devtools/client/fronts/walker.js#135

Unfortunately, I'm getting back empty objects (not errors!) when passing pause event grips like the below to that function:

{type:"object", actor:"server0.conn1.child2/obj166", class:"HTMLElement", ownPropertyLength:2, extensible:true, frozen:false, sealed:false, preview:{kind:"DOMNode", nodeType:1, nodeName:"section", isConnected:true, attributes:{class:"collapsible-section top-sites animation-enabled collapsed", 'aria-expanded':"true", 'data-section-id':"topsites"}, attributesLength:3}, contentDomReference:{browsingContextId:18, id:0.6769711448788546}}

Important note, that could be the problem: in experimenting with the above, I've called the gripToNodeFront function on walkerFronts on random instances of nodeGrips because that is the only place that code exists right now. That could be the cause of the empty returns, but I'm not sure it is because the gripToNodeFront looks to be purely functional.

The only other way I've found people converting nodeGrip to nodeFront on the front-end is using the inspectorFront. See: https://searchfox.org/mozilla-central/rev/c2bc259414706ef4be5d13df1344eebb7507a51b/devtools/client/dom/content/components/DomTree.js#77

Unfortunately, DomProvider does not exist in the debugger pane.

Instead of matching on nodeActor, we could also match on contentDomReference. There is no way to get a contentDomReference from a nodeFront on the front-end is there?

Thank you for checking this out haydenbetts! You ran into the roadblocks that I ran into as well. :nchovebbe Do you know if anything has changed in the past six months with regard to grips and fronts that are available for both inspector and debugger?

We do have things in place that would retrieve the right highlighter to talk to.
I think everything should be in place if you're using the highlighter we retrieve from the toolbox (https://searchfox.org/mozilla-central/rev/a707541ff423ade0d81cef6488e6ecfa09273886/devtools/client/debugger/panel.js#148) and pass the right props to the reps.

Hayden, could you push your patch to phabricator so I can see what's missing to make it work?

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.