Mysterious failure when a page contains too many children

[tearseb2]

While attempting to create a tabbed interface for a tool, I found that having too many children inside of one of the "page" divs of an iron-pages element breaks the functionality. Here's the relevant chunk of the page:

<iron-pages id='test'>
  <div id='problem-content'>
    <table>
     <tr><td>blah</td></tr>     <-- Repeated X times
    </table>
  </div>

  <div>Blah</div>
</iron-pages>

JS executed via console:

var temp = document.getElementById('test');
temp.selectNext();

This properly switches between the two divs (the one with the many rows and the one with "Blah") when x (the number of repeated rows) is 250 but does not (and provides no js error in the console) when x is 12000. When broken, the selectNext() method call doesn't append the 'iron-selected' class to the second div and leaves the first div with a strange artifact class (i.e. <div id='problem-content' class>). Manually applying the class='iron-selected' attribute to the second div still makes it appear properly.

Additional Info 1: I tried altering the html such that the table and its rows were replaced by divs but that didn't alter the behavior:

<iron-pages>
  <div id='problem-conent'>  
    <div>blah</div> (repeated x times) 
  </div>
</iron-pages>

Additional Info 2: I tried breaking the functional page with the 250 divs by adding a bunch of new divs via the console:

var addFun = function(parent, num) {
  var temp = document.createElement('div');
  temp.innerHTML=num;
  parent.appendChild(temp); 
};

var content = document.getElementById('problem-content');
for(var i=1; i<13000; i++) { addFun(temp, i); }

This caused the 13000 new divs to be added correctly but the resulting page still worked.

Thus: This problem seems to only be exhibited when the content is all there while the page loads.

[tearseb2]

Ran another experiment: Swapping the order of the divs (so the 'short' div starts displayed) actually alleviates the problem in my test example. Sadly my use-case is swapping pages between two views of the same data so each page is equally huge but this coupled with Additional Info 2 (from the original issue) indicates that the problem may have something to do with page load rather than the content of the iron-page when the selectNext() method is called.

[rictic]

It sounds like this is a case where iron-pages fixates on its children before page load is finished and doesn't notice as more are added.

Changes have landed to this behavior somewhat recently, I'll message you privately with info on how to test your internal code with the latest code from github.

[tearseb2]

You're correct about the fixating. When I call up the .items attribute of the iron-pages element it only lists the first element. I can manually add the second div to the .items array and then .selectNext() works properly.

[rictic]

What happens if you call _updateItems() on the iron-pages element after it's loaded?

I wonder if we need to listen for DOMContentLoaded in iron-selector...

[rictic]

\cc @cdata who's done a lot of the work on iron-selector

[psquared2]

This happens at iron-pages 1.0.8 - even with a page with 64 (recursively counted) children