element loses selected state under complex circumstances due to dom-change event listener

[n1ywb]

2a38231#diff-13549f957703a50cf7279a9976ac1f77R187

this method receives dom-change events triggered by nested sub-templates, not just by the immediately enclosed template

when one of those sub-templates fires this event, AND the iron-swipeable-pages widget is not currently visible, THEN it defaults to fallback selection and loses it's state;

when the widget becomes visible again, it remains invisible, because it's selected==null

it's not easy to restore the state; a one-way databinding doesn't work because the property effects don't engage because the value hasn't "changed" (synchronous events). a two way binding just gets overwritten with the new fallback value. the only way I can think of to work around this
would be to bind to dom-change myself; yuck.

I'm not 100% what the intent of this code was. Something about hiding blank pages? I commented it out without any apparent ill effect. Do we really need it? If this is critical functionality can we find a better way to implement it with fewer side effects?

here's a contrived example

<iron-pages>
  <div name="view1">view one stuff</div>
  <div name="view2">
    <iron-swipeable-pages>
      <template id="outer-template" is="dom-repeat" items="[[outerItems]]">
        <page item="[[item]]">
          <template id="inner-template" is="dom-repeat" items="[[innerItems]]">
            <li>[[innerItem]]</li>
          </template>
        </page>
      </template>
    </iron-swipeable-pages>
  </div>
</iron-pages>

1. when the user switches from view2 to view1, iron-swipeable-pages is hidden
2. when the user does something in view1 that affects innerItems in view2, inner-template fires dom-changed
3. iron-swipeable-pages gets dom-changed and set's the selection to the fallback which is null
4. when the user switches back to view2 it's blank because iron-swipeable-pages.selected == null

[n1ywb]

Proposed change n1ywb@e67a8d6

[MeTaNoV]

the use-case was if I remember well, some nested dom-if inside dom-repeat which under some circumstances led to the disappearing of the current page, which if not directed to the fallback introduced a problem...