Bug 121665 – Web Inspector: Keep DOM tree expanded on page reload

• Status: RESOLVED
• Resolution: FIXED
• Component: Web Inspector

[Ben Frain]

When inspecting a web page with Web Inspector it's common to drill down the DOM tree and select an element to Inspect. Having altered that element externally the page is then reloaded. However, when the page is subsequently reloaded the DOM tree is then totally collapsed necessitating drilling down through the DOM again. When iterating through site designs this makes for an extremely tiresome debugging experience.

Can we see the same action as the Chrome/Firefox dev tools whereby the current expansion state of the DOM is retained on subsequent page loads?

[Radar WebKit Bug Importer]

<rdar://problem/15038868>

[Antoine Quint]

Created attachment 212707 [details]
Testcase

The attached test case shows that if you inspect the black rectangle, which is <div> nested 10 levels deep, and hit reload, we more often than not expand to the same place in the tree again. However, there are cases when we do not. Trying the same thing in the Chrome inspector seems to work a lot more reliably.

[Antoine Quint]

Created attachment 212711 [details]
Patch

[Antoine Quint]

Attached patch seems to work well with pages I've tested (apple.com, store.apple.com, lemonde.fr) but doesn't work for pages where the selected content had been generated by script, which also fails in the Chrome Web Inspector. I think this patch brings us to parity with Chrome.

[Joseph Pecoraro]

Comment on attachment 212711 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=212711&action=review

> Source/WebInspectorUI/UserInterface/DOMTreeContentView.js:-300
> -            // A selection was made while waiting for the async reply. Just bail now.
> -            if (this._domTreeOutline.selectedTreeElement)
> -                return;

I think this will regress a rarer scenario (the reason this code was originally added).

However, I think we should take this patch, which improves a very common case, and we should address the rare scenario in a different way.

I would guess the scenario this breaks is:

  1. Inspect for apple.com
  2. Inspect the inspector (aim to inspect element something deep in the tree, like a deeply nested DOM node in the DOM tree)
  3. When inspector² opens, quickly select something else in the DOM tree, like the Quick Console node
    => after a few beats, the DOM Tree will switch to show the originally selected "inspect element" node

I think we would want to do something like this bail only if "a <em>user</em> selection was made while waiting for the async reply".

[Ben Frain]

The principal reason this came to my attention was inspecting the iOS simulator. Viewing and inspecting any web page there causes this issue.

[WebKit Commit Bot]

Comment on attachment 212711 [details]
Patch

Clearing flags on attachment: 212711

Committed r156481: <http://trac.webkit.org/changeset/156481>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.