modal paper-dialog wrongly shown when inside a drawer

[valdrinkoshi]

From @kungufli on October 7, 2015 13:39

If you have a modal paper-dialog inside the drawer of a paper-drawer-panel, when the drawer is in narrow state the dialog is shown under the overlay:

The overlay is correct if the drawer is not narrow:

Also, note that the paper-dialog sizing is wrong when the drawer is narrow. Obviously this can be solved by moving the paper-dialog tag outside of the drawer, but this is still a bug, in my opinion, because there are cases when this complicates the code, for example if you need to use paper-dialog inside an element that should be positioned in the drawer.

Copied from original issue: PolymerElements/paper-dialog#44

[valdrinkoshi]

From @jesusabarca on October 9, 2015 0:58

I'm having the same issue. I tried placing the <paper-dialog modal></paper-dialog> element in different places, but I'm having the same behavior. On a desktop is not a big deal, but in a mobile device, it gets lost on the edges of the screen.

[valdrinkoshi]

From @kungufli on October 19, 2015 10:20

An interesting detail: this bug is present in latest versions of Chrome (46.0.2490.71) and Firefox (41.0.2), but the dialog works normally in Microsoft Edge and IE (tested on 11 and 10).

[valdrinkoshi]

From @ronnyroeller on October 21, 2015 12:29

+1

[valdrinkoshi]

From @jpodwys on December 9, 2015 17:16

+1

[valdrinkoshi]

From @jshcrowthe on December 15, 2015 0:29

Any updates on this?

[valdrinkoshi]

This is not caused by the paper-dialog, but by the way overlays are handled in iron-overlay-behavior; the backdrop is always added to body and it's shared between overlays. The fact that you insert the dialog in another branch of the DOM tree causes issues with the z-index system. There is a proposal PR that fixes this, but potentially introduces other issues related to css selectors (breaking change).

In the meantime, consider moving your paper-dialog outside the paper-drawer-panel. Ideally overlays should be children of body (since they'll always show on top of everything else).

[valdrinkoshi]

After further debugging, i discovered that the css property will-change: transform is causing the issue. Will move it to the right repo

[valdrinkoshi]

@blasten FYI, here a jsbin http://jsbin.com/besiwo/edit?html,output

[blasten]

@valdrinkoshi In my opinion, the issue is that we need a system that takes into consideration how stacking contexts are created. There's a list of CSS properties that are very handy for a lot of use cases yet they create a stacking context. I think removing will-change or the translateZ hack would decrease the performance of the animation when the drawer opens and it won't fix the issue for all the elements. https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/The_stacking_context

[valdrinkoshi]

@blasten since this is a problem with overlays, maybe is worth further exploring a solution like this https://github.com/PolymerElements/paper-dialog-behavior/pull/56 which will reset all these properties that affect the stacking context while the overlay is opened.

[valdrinkoshi]

Closing this one, as is an issue related with iron-overlay-behavior and stacking context.

[mlisook]

As a comprehensive fix will likely take some time, and the recommended work around of moving the paper-dialog outside the paper-drawer-panel can be tricky, I thought I'd offer an alternative workaround.

A non modal paper-dialog still works fine inside the paper-drawer-panel, even in another custom element inside the drawer. And of course, one could reasonably manage attempts to dismiss outside the desired method, if required.