I'm using DOM inspector in the sidebar for "debugging" complicated HTML and find it quite annoying that I'm forced to delve into deeply nested tables (sometimes 20 elements deep) from the start (body element) every time the page is reloaded, even if the tree did not change that much. It would be much better if the DOM inspector builds some sort of diff between the old and the new tree view and then applies that diff to the view of the tree view, so that no unnecessary node collapsing takes places, and so that the selected node in the inspector tree widget stays the same (provided that element still exists in the new tree view). I understand that for very large DOM trees this could be quite slow, but some heuristics could be used to only apply this feature if the DOM node is sufficiently small, and to update the tree widget the normal way otherwise (read: like it is currently done).

Well, hmm. The issue is that when you reload the page, the original document is destroyed and recreated from scratch. This is not done by inspector but rather by the DOM. So, after this, the entire tree view obviously must then be recreated. One thing that we could possibly do is store the URL of the page, and some information about the tree view. Then when we recreate a DOM structure and its subsequent tree view, if the URLs match, attempt to restore the state of the tree. Perhaps something similar to what layout save and restore does?

Yes, you could remember what things were open using a list of XPath IDs of open content, for example. When (if?) save/restore becomes better and more pluggable, you may be able to ask the save/restore system itself to save information like this for you. Setting dependent to bug 166636 even though this can be solved without it.

*** Bug 192439 has been marked as a duplicate of this bug. ***

Related to this is bug 111411.

DOM Inspector can modify the page. What if the user wants to see the page without modifications? Should he or she undo a bunch of Inspector actions, or should he just reload the page?

Mass re-assigning bugs to dom.inspector@extensions.bugs

We can probably do this by storing an XPath of the current node, then when a reload happens, if the XPath matches, go straight to that, if not... do whatever we do now.

Bulk close. This component is no longer supported or maintained. https://bugzilla.mozilla.org/show_bug.cgi?id=1499023

Bulk close. This component is no longer supported or maintained. https://bugzilla.mozilla.org/show_bug.cgi?id=1499023