181261 - DOM Inspector should try not to rebuild the entire tree view upon page reloads

Status: RESOLVED INCOMPLETE

(Other Applications :: DOM Inspector, enhancement)

Description

[Timon Christl]

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).

Comment 1

[Christopher Aillon (sabbatical, not receiving bugmail)]

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?

Comment 2

[John Keiser (jkeiser)]

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.

Comment 3

[Alex Vincent [:WeirdAl]]

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

Comment 4

[Alex Vincent [:WeirdAl]]

Related to this is bug 111411.

Comment 5

[Alex Vincent [:WeirdAl]]

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?

Comment 6

[Christopher Aillon (sabbatical, not receiving bugmail)]

Mass re-assigning bugs to [e-mail]

Comment 7

[Michael Gall]

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.

Comment 8

[Firefox Bug Husbandry Bot]

Bulk close. This component is no longer supported or maintained.

https://bugzilla.mozilla.org/show_bug.cgi?id=1499023

Comment 9

[Firefox Bug Husbandry Bot]

Bulk close. This component is no longer supported or maintained.

https://bugzilla.mozilla.org/show_bug.cgi?id=1499023