Bug 121665 - Web Inspector: Keep DOM tree expanded on page reload
Summary: Web Inspector: Keep DOM tree expanded on page reload
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Antoine Quint
Keywords: InRadar
Depends on:
Reported: 2013-09-20 02:32 PDT by Ben Frain
Modified: 2013-09-26 11:28 PDT (History)
5 users (show)

See Also:

Testcase (352 bytes, text/html)
2013-09-26 07:50 PDT, Antoine Quint
no flags Details
Patch (1.70 KB, patch)
2013-09-26 08:09 PDT, Antoine Quint
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ben Frain 2013-09-20 02:32:43 PDT
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?
Comment 1 Radar WebKit Bug Importer 2013-09-20 02:33:05 PDT
Comment 2 Antoine Quint 2013-09-26 07:50:14 PDT
Created attachment 212707 [details]

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.
Comment 3 Antoine Quint 2013-09-26 08:09:18 PDT
Created attachment 212711 [details]
Comment 4 Antoine Quint 2013-09-26 08:10:55 PDT
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.
Comment 5 Joseph Pecoraro 2013-09-26 10:44:06 PDT
Comment on attachment 212711 [details]

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".
Comment 6 Ben Frain 2013-09-26 11:27:35 PDT
The principal reason this came to my attention was inspecting the iOS simulator. Viewing and inspecting any web page there causes this issue.
Comment 7 WebKit Commit Bot 2013-09-26 11:28:42 PDT
Comment on attachment 212711 [details]

Clearing flags on attachment: 212711

Committed r156481: <http://trac.webkit.org/changeset/156481>
Comment 8 WebKit Commit Bot 2013-09-26 11:28:44 PDT
All reviewed patches have been landed.  Closing bug.