Bug 166906 – Web Inspector: when Layers sidebar is open, elements that have an associated compositing layer should be more prominent in DOMTreeOutline

• Status: NEW
• Component: Web Inspector

[Blaze Burg]

It's really bad experience to go dig into the Layers sidebar whenever you want to see where the layers are in the tree. Let's show an icon, either all the time or when the Layers sidebar is open.

[Radar WebKit Bug Importer]

<rdar://problem/29956123>

[Devin Rousso]

Are you suggesting we visually distinguish nodes with layers in the DOM tree?  If so, would it make sense to dim all nodes without layers when the layer sidebar is open?

On another note, from what I can tell it looks like the current method of retrieving layer information is from `WebInspector.layerTreeManager.layersForNode`.  If this is true, then I think it may make sense for us to only retrieve layer info for nodes when the parent is expanded in the tree.  I'm just worried about how well this will perform on pages with large numbers of DOM nodes.  Suggestions are welcome :D

[Blaze Burg]

(In reply to comment #2)
> Are you suggesting we visually distinguish nodes with layers in the DOM
> tree?  If so, would it make sense to dim all nodes without layers when the
> layer sidebar is open?
> 
> On another note, from what I can tell it looks like the current method of
> retrieving layer information is from
> `WebInspector.layerTreeManager.layersForNode`.  If this is true, then I
> think it may make sense for us to only retrieve layer info for nodes when
> the parent is expanded in the tree.  I'm just worried about how well this
> will perform on pages with large numbers of DOM nodes.  Suggestions are
> welcome :D

Calling layersForNode(root) will retrieve all the layers in the document. If you look at the backend, it does a BFS traversal of the render tree and layer tree (not the DOM tree) to collect these. This is fairly cheap afaik; we do this all the time during rendering. Viewing layers on apple.com for the root node is instantaneous, which is good enough for me.

[Blaze Burg]

(In reply to comment #2)
> Are you suggesting we visually distinguish nodes with layers in the DOM
> tree?  If so, would it make sense to dim all nodes without layers when the
> layer sidebar is open?

Dimming when showing layer sidebar sounds like a fine first step. We can think about adding actual icons later. I want to do something like this for event listeners and other node-attached things, but we should probably defer that until we have some better ideas for how such information can be displayed without visually overloading the tree outline. (For example, we could have a filter icon in the nav bar that lets you toggle each of these things on/off, even if you aren't looking at the respective sidebar).

[Devin Rousso]

(In reply to comment #4)
> Dimming when showing layer sidebar sounds like a fine first step. We can
> think about adding actual icons later. I want to do something like this for
> event listeners and other node-attached things, but we should probably defer
> that until we have some better ideas for how such information can be
> displayed without visually overloading the tree outline. (For example, we
> could have a filter icon in the nav bar that lets you toggle each of these
> things on/off, even if you aren't looking at the respective sidebar).

I actually really like the idea of using a filter icon in the nav bar.  I think that may be a better starting point than trying to sync displaying the Layers sidebar and showing indicators in the DOM tree.

[Blaze Burg]

(In reply to comment #5)
> (In reply to comment #4)
> > Dimming when showing layer sidebar sounds like a fine first step. We can
> > think about adding actual icons later. I want to do something like this for
> > event listeners and other node-attached things, but we should probably defer
> > that until we have some better ideas for how such information can be
> > displayed without visually overloading the tree outline. (For example, we
> > could have a filter icon in the nav bar that lets you toggle each of these
> > things on/off, even if you aren't looking at the respective sidebar).
> 
> I actually really like the idea of using a filter icon in the nav bar.  I
> think that may be a better starting point than trying to sync displaying the
> Layers sidebar and showing indicators in the DOM tree.

What I imagine is clicking on the icon shows a native drop-down with checkable modes, like the Develop menu, just like long-clicking the New Tab tab item. We are already running out of room for more single purpose icons so we may be able to consolidate some other things this way (paint flashing + compositing borders come to mind).

My strawman proposal is to group these by where the effect is visualized: on the inspected page (flashing, layer borders) or on the tree outline (event listeners, layers, etc).