search

GoogleChrome / dialog-polyfill

Polyfill for the HTML dialog element
BSD 3-Clause "New" or "Revised" License
2.45k stars 245 forks source link

Cross-browser modal issue in Safari #105

Closed scloo closed 7 years ago

scloo commented 8 years ago

Looks like the modal functionality has issue on the Safari. I have a login dialog modal. On firing up, the dialog came up fine. The moment you click any where on the screen (including the dialog), everything becomes unresponsive to the mouse click, including the dialog itself. I will not be able to access the form input fields or anything else for that matter.

Basically the whole page gets locked out including the dialog. To unlock it, I go into the console and disable the z-index for the _dialog_overlay. But this disables the dialog_overlay and hence breaking the modal functionality.

Is there any workaround for this problem? Is this a known modal issue with other browser like Safari?

Thanks

scloo commented 8 years ago

If I remove the 'bottom: 0" from the css for _dialog_overlay ,the dialog becomes available. But it basically disable the modal functionality, making it like the regular dialog without modal.

I have tested your modal demo in Safari and it works fine. I just can't see what I have missed. Unless the fact that I am running under Backbone JS view environment might have complicated the case. But it works without a hitch under Chrome.

prasadsilva commented 8 years ago

I'm running into this too, but I think on my end the issue is related to the following limitation (per README):

They should be a child of or have parents without layout (aka, no position absolute or relative elements)

I'm using react-mdl, and the dialog elements are being created inside the content section of a page that uses layout to support a responsive header and a navbar.

5amfung commented 8 years ago

I have similar issue with Safari that the modal doesn't close. However hitting the esc key did close the modal.

samthor commented 8 years ago

@Garbee look at @prasadsilva 's comment.

A nice fix is to set them to be position: fixed (why this wasn't part of the spec I have no idea) and fix the related CSS of that. That way they just live in the middle of the screen regardless of viewport and don't care about layout.

Garbee commented 8 years ago

Ah, interesting. I'll take a look at this on Thursday or Friday if I have time. That sounds like a great fix.

samthor commented 7 years ago

Closing this as it's related to incorrect use of stacking context. We now warn if you're making a mistake, and also are more permissive, so incorrect usage might still work: #131