1575660 - Add ability to see the stack trace which created a node in the devtools inspector

Status: NEW

(DevTools :: Inspector, enhancement, P3)

Description

[Thomas Wisniewski [:twisniewski]]

Chrome is adding a new feature to be able to see the stack trace which lead to a particular node being added to a page, in a "stack trace" panel in the node inspector: https://twitter.com/cjamcl/status/1156033960389951488

This would be a very useful tool for diagnosing complex pages, which would be nice to see in the Firefox devtools as well (I currently use a variant of such a tool in my Tinker Tester Developer Spy diagnosis addon).

Comment 1

[:Harald Kirschner :digitarald]

Sounds like something like DOM Mutation Logpoints could help here as well, but filtered down to the selected element.

For the Chrome feature, I'd be curious to see if it will ever leave the Experiments page, as it is very intrusive.

Comment 2

[Thomas Wisniewski [:twisniewski]]

For the record, log points/breakpoints are what Tinker Tester effectively lets me set; I can select the node name(s) I want to monitor for, and it will log traces or start the debugger. This lets me know when a node is created, regardless of whether it is attached to the tree.

Alternatively, the addon can also listen for a given CSS-selector to match on DOM Mutations (or cease matching), which can be even more useful as I sometimes wish to know when the node has a specific set of attributes/conditions match, rather than simply knowing when it has been added/removed to the tree, or is simply created.

Comment 3

[Julian Descottes [:jdescottes]]

Hi Tom,

Just curious if this would be a priority for webcompat? I don't think it's been triaged recently but there were discussions today on Elements about it. Probably not trivial but if that can be important for webcompat team, maybe we should prioritize again.

Comment 4

[Thomas Wisniewski [:twisniewski]]

Pardon the delay, Julian, I was on PTO. It's not a terribly high priority, but especially but in the era of React and other frameworks which obscure what triggered a given element to be added to the DOM, it's often useful to get the stack trace to determine what triggers an elements are being created (especially shadow DOM ones).

Another approach might be for DOM MutationRecords to have a new property with the async stack trace for which code caused the mutation (even as a disabled-by-default option). That way we could just open the console, set a mutation observer which monitors for specific types of elements and logs their traces, and then trigger the page to add the node. UI could then be added on top of that as time permits (even via addon).

Comment 5

[qthang07]

Hello everyone, I had built a new debugging tool in firefox devtools that allow user to view all of stack trace of element's modification in web page. Compare to existed tool DOM Mutation Breakpoint, this tool can track code which create new element, and allow user to view stacktrace for which
code caused the mutation of target element even if this element is not added into DOM yet. So, if you allow, i want to share my work here and get your opinions about it.

Comment 6

[Nicolas Chevobbe [:nchevobbe]]

(In reply to qthang07 from comment #5)

Hello everyone, I had built a new debugging tool in firefox devtools that allow user to view all of stack trace of element's modification in web page. Compare to existed tool DOM Mutation Breakpoint, this tool can track code which create new element, and allow user to view stacktrace for which
code caused the mutation of target element even if this element is not added into DOM yet. So, if you allow, i want to share my work here and get your opinions about it.

you can definitely share it here, I'm curious how it works and looks :)

Comment 7

[qthang07]

Attachment: Figure showing the procedure for using J2CM

Jump to Construction and Mutation feature

1. Overview
   Jump to Construction and Mutation (J2CM) is a debugging tool built in the Firefox browser. It records dynamic modification of HTML elements displayed on the web page.

J2CM is built based on the implementation of DOM Mutation Breakpoint in Firefox. But, compared to existed DOM Mutation Breakpoint tool in devtools, J2CM can:
• Record DOM modification when page is loading
• Record creation of elements
• Record modifications of elements before these elements are added into DOM

2. Usage
   The attached figure shows how to use J2CM on the browser.
   • Step ①: Click on the icon of the “select node in webpage” tool to enable it
   • Step ②: Click on a node which you want to view
   => After ②, all modifications that occurred to that node will be displayed on the right panel
   • Step ③: Click on [index.js:47:27] to jump to 47th line of index.js in the debugger

Event history is a list of recorded modifications which occurred to a selected node. In events history, events are displayed from top to bottom in order of their occurrence.

Call stack is a stack trace for a recorded modification.

3. Implementation
   J2CM works based on several event listeners to collect modifications of elements on the web page.
   • devtoolsNewElementCreated event for Node Creation
   • devtoolsAttrModifiedOnNode event for Attribute Modification
   • devtoolsChildInsertedOnNode event for Childnode Insertion
   • devtoolsChildRemovedOnNode event for Childnode Removal

Whenever DOM manipulation happens, a specific event will be dispatched which after that causes the corresponding listener (handler function) to run and collect the call stack at this time.

4. Limitation
   J2CM is a result of my graduation research. Because of limited time, it still has several limitations that need to be improved.

Firstly, J2CM implementation is still not decoupled from existing code.

Secondly, there is still no way to collect all dynamically created nodes on the web page. In J2CM, I just added some code at the end of createElement() method to dispatch the devtoolsNewElementCreated event. I supposed that, we need to modify the element configuration class in firefox/dom to dispatch this event whenever a new element is added to the element pool.

Lastly, because of tracking modification of all elements on the web page, J2CM may cause the browser to crash if there are too many modifications. For example, a page using js to implement animation or slideshow, …. One of the solutions for this problem is that for each node we set a default number which is a limit of modifications that can be recorded. For example, We set up that J2CM will take the first 10 modifications of element by default. And allow users to change to 20 or 30 if they need to.

Comment 8

[qthang07]

Attachment: hg diff file for the implementation of the Jump to Construction and Mutation feature

Comment 9

[Nicolas Chevobbe [:nchevobbe]]

Thanks a lot qthang07
Do you think you could post your patch to phabricator: https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html#to-submit-a-patch
So it will be easier for us to review what it's doing.
Also, would you be willing to continue working on this and try to have it landed in the Inspector?

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

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 BugBot documentation.