1254671 - Tag names and attribute names/values go missing from the inspector at some depth of DOM nesting

Status: NEW

(DevTools :: Inspector, defect, P3)

Description

[Hallvord R. M. Steen [:hallvors]]

Attachment: TC: devt-nest.htm

Discovered when trying to understand bug 1073463: if the DOM is nested deeper than $arbitrary_limit the inspector starts being weird. It outputs one level of tags without attribute names and values, then one level of tags without even tag names, then nothing at all:

<div ="" ="">
  </>
</div>

There's more stuff in the DOM inside this DIV but the inspector can't show it.

Comment 1

[Brian Grinstead [:bgrins]]

Can confirm - if you alt+click on the tag for me then it starts to fail after data-depth="91"

Comment 2

[Patrick Brosset <:pbro>]

Confirmed too. This is extremely weird because I think the markup and content is there in the DOM, just not displayed.

For instance, on the test page, alt-click to expand all, then scroll down and right until the problem starts to shows.
Select a node that has no attributes displayed.
Then in scratchpad in browser mode, do:

var i = [...gDevTools._toolboxes][0][1].getPanel("inspector");
var n = i.selection.nodeFront;
i.markup.getContainer(n).editor.elt.textContent;

This logs:
<div data-depth="92" align="left"></div>ev

Which means that the attributes are there in the DOM, but somehow not displayed.
It's hard to debug using the browser toolbox inspector because this one also has the problem and I can't select the 92th node ...

Also, there are no errors in the browser console.

This is a pretty important one that we should investigate now, flagging accordingly.

Comment 3

[Julian Descottes [:jdescottes]]

As Patrick said, the outerHTML of the markup view contains all the markup needed to display the information. 

There seems to be a limitation in the DOM that can be displayed in the markup-view's iframe. If the iframe's HTML contains elements nested more than 200 levels, they won't be displayed.

Comment 4

[Patrick Brosset <:pbro>]

(In reply to Julian Descottes [:jdescottes] from comment #3)
> As Patrick said, the outerHTML of the markup view contains all the markup
> needed to display the information. 
> 
> There seems to be a limitation in the DOM that can be displayed in the
> markup-view's iframe. If the iframe's HTML contains elements nested more
> than 200 levels, they won't be displayed.
Indeed, reproduced with a reduced test case on jsbin: http://jsbin.com/numulatame/1/edit?js,output

Comment 5

[Julian Descottes [:jdescottes]]

We are actually hitting the rendering limit described in Bug 256180. Turns out this affects any document, not just iframes.

pbro: Simply marking as blocked, since Bug 256180 has not been updated in a long time, I am a bit reluctant to close this one as duplicate straight away. Feel free to close if you prefer, though.

Comment 6

[Julian Descottes [:jdescottes]]

FWIW, the limit of 200 is now defined at https://dxr.mozilla.org/mozilla-central/source/layout/generic/nsIFrame.h#16

Comment 7

[Patrick Brosset <:pbro>]

Marking as blocked sounds good to me. Let's just move this to the backlog instead of it being a P1. There's no solution on our side we could use, so this isn't an urgently blocking bug that we can act on right now.

Comment 8

[Brian Grinstead [:bgrins]]

This seems like it'd be a lot of work, but a possible workaround would be if the tree was laid out without DOM nesting and instead having a flat list of nodes with something like a data-depth attribute that controls both the visual indent and expand / collapse behavior.

Or maybe we could ask if the limit could be increased for chrome frames.

Comment 9

[Hallvord R. M. Steen [:hallvors]]

Yeah, I thought it was something like that. Note that the attached TC also tests this (like pbrosset's jsbin test) - it attempts to nest elements down to a depth of 250 and it fails silently.

Opera Dragonfly (RIP) was pretty fast because it only actually put the stuff you needed to see into the DOM.. Scrolling would add/remove nodes. It sounds kludgy but from a user perspective it actually worked great. Something similar would presumably also work around this problem (but be a massive change).

Comment 10

[Patrick Brosset <:pbro>]

If we're going to do a complex refactor of the markup-view, we should use the opportunity to use react & redux (see bug 1118692).

Comment 11

[forkest]

Screenshot tool doesn't work for me on one such highly nested page. I decided not to post it as another bug, since the elements nested there are of one type, and once I delete the most nested but still visible node with all its children, I can take screenshots again. So I believe that patching this bug should fix that automatically.

Comment 12

[Julian Descottes [:jdescottes]]

Unassigning myself, not actionable at the moment unless we rewrite the markup view from scratch or Bug 256180 gets fixed.

Comment 13

[Henri Sivonen (:hsivonen)]

This has been fixed for this test case, but the limit hasn't gone away: It has just been increased.