Absurd problem with tabs when containing an element with <paper-input>

[mercmobily]

Description

When a MODAL paper-dialog contains another element with paper-inputs, the paper-inputs don't get cycled with the tab key.

<paper-dialog modal>
  <i-contain-paper-inputs><i-contain-paper-inputs>
</paper-dialog>

Now the fun begin. If there is ONE paper-input before i-contain-paper-inputs, that field gets exclusive focus:

<paper-dialog modal>
  <paper-input></paper-input>
  <i-contain-paper-inputs><i-contain-paper-inputs>
</paper-dialog>

And... guess what? If TWO paper-inputs precede i-contain-paper-inputs, then... everything works perfectly well. Yes, you read it right... this works. 100%. here:

<paper-dialog modal>
  <paper-input></paper-input>
  <paper-input></paper-input>        
  <i-contain-paper-inputs><i-contain-paper-inputs>
</paper-dialog>

Expected outcome

I expect tab to work even without having two paper-inputs. This is a common scenario: a dialog pops up, and the user is required to key in some info

Actual outcome

It depends on the number of paper-input elements preceding i-contain-paper-inputs (!).

Live Demo

I am sorry, no live demo for this. I am having a tiff with jsbin.
However, I made it as simple as possible:

$ mkdir polytest
$ cd polytest
$ polymer init

And then copy over these two files:

polytest-app.html

<link rel="import" href="../../bower_components/polymer/polymer.html">
<link rel="import" href="../../bower_components/paper-dialog/paper-dialog.html">
<link rel="import" href="../../bower_components/paper-input/paper-input.html">
<link rel="import" href="my-el.html">

<dom-module id="polytest-app">
  <template>
    <style>
      :host {
        display: block;
      }
    </style>

    <paper-dialog opened modal>

      <!-- Add one input, and it will take the focus... -->
      <paper-input></paper-input>

      <!-- Add one more, and tabbing will work! -->
      <paper-input></paper-input>

      <my-el></my-el>
    </paper-dialog>
  </template>

  <script>
    Polymer({

      is: 'polytest-app',

      properties: {
        prop1: {
          type: String,
          value: 'polytest-app',
        },
      },

    });
  </script>
</dom-module>

my-el.html

<link rel="import" href="/bower_components/polymer/polymer.html">

<dom-module id="my-el">
  <template>

    <style>
    </style>
    <h1>In my-el!</h1>
      <paper-input></paper-input>
      <paper-input></paper-input>
      <paper-input></paper-input>
  </template>

  <script>
    Polymer({
      is: 'my-el',
    })
  </script>

</dom-module>

Steps to reproduce

Uncomment the paper-input elements in my-el.html.
Note: in my application, I am doing:

  <paper-input style="display:none;"></paper-input>      
  <paper-input style="display:none;"></paper-input>

(!)

Browsers Affected

• Chrome
• Firefox
• [?] Safari 9
• [?] Safari 8
• [?] Safari 7
• [?] Edge
• [?] IE 11
• [?] IE 10

[mercmobily]

I have the slight feeling I will win "bug of the year" award for this one. However, it will be followed by the "workaround of the decade" award!

It took a lot of persistence and testing to get this one nailed, I hope the solution is simpler than actually finding the problem...

[valdrinkoshi]

Hi @mercmobily, I think it's a tie with this other bug!
Handling tabbing and focus is absurd, moreover here we add the complexity of moving the focus between shadow roots..just for fun, try playing with these examples! code - demo

iron-overlay-behavior tries to help in finding what's the first & last focusables in its light dom to wrap the focus, but fails because focus is hard.

Truth is the platform should help us on this! Ideally we'd need something like document.blockingElements which would allow paper-dialog and any focus-trapping element to do

// on open
document.blockingElements.push(this);

// on close
document.blockingElements.remove(this);

Until then, I'm working on fixing the fixable in here PolymerElements/iron-overlay-behavior#200; here the same example above using the iron-focusables-helper branch code - demo

[mercmobily]

The proposal for blocking element stack looks a little "bogged", with Dominic's last message being:

I'm going to back off my involvement in this thread as it seems that at this point we've exhausted discussion on the original proposal and are starting to go off-topic. Additionally, I've still yet to see any explicitly stated implementer interest (of the form "yes, $browser would implement this once it's specced") which is what this proposal needs to move forward---not more features. When such interest emerges from two implementers I'll be able to shift some of my resources back toward it.

So yes, platform help would be help, but I think your "band aid on steroid" solution is very much welcome and needed.
In the meantime, I will have the two hidden paper-input elements there. But... really... :D