Dialog takes over focus on Stripe checkout input elements.

[sturoid]

I'm trying to use the stripe checkout (react-stripe-checkout package) on top of a Dialog. Before I upgraded to the new version of material-ui (previous was 0.19.4) it worked fine. I upgraded to 4.9.2. Now when the dialog is open and Stripe checkout is on top, if you click any of the inputs, they will focus for a split second, and then lose focus. I've tried to look at events happening on the page and it looks like some events are added to the inputs when on top of the dialog. When not over the dialog, the checkout works as expected. This happens on the latest versions of Chrome, Firefox, and Safari. Any help or input is very much appreciated.

• The issue is present in the latest release.
• I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯

When the Stripe Checkout modal is on top of a dialog, the Stripe inputs gain focus on click, and then immediately lose focus.

Expected Behavior 🤔

On 0.19.4 everything works as expected. I have a Stripe Checkout modal above the material ui dialog and I can interact with the form.

Steps to Reproduce 🕹

Steps:

1. Install react-stripe-checkout.
2. Install the latest @material-ui/core
3. Open a dialog and then stripe checkout on top of it.
4. Click on a form input to see it gain and then lose focus.

Context 🔦

Tech	Version
Material-UI	v4.9.2
React	v16.12
Browser	Latest Chrome, Firefox, Safari
react-stripe-checkout	v2.6.3

[sturoid]

I was able to get this to work but only with a specific setup using the Modal component instead of the Dialog component

<Modal open={open} onClose={onClose} className={classes.modal}>
  <>
     <div className={classes.paper}>{children}</div>
  </>
</Modal>

Without the "<> </>" wrapping the div/children inside the Modal, it had the same problem as the Dialog. I'm not sure what that is doing but it works.

[eps1lon]

Thanks for opening this issue and providing some context.

Could you include a reproduction (perferably a codesandbox).

The Dialog is trapping focus inside itself. If there's another modal window and the dialog isn't aware that it is inert it will steal focus. But we need an actual example to debug this issue.

[oliviertassinari]

I can't reproduce it either: https://codesandbox.io/s/stripe-vuzyv.

---

However, I think that it would be interesting to push #17497 (comment) further, it feels like that the interval we have introduced doesn't match the scale of the problem we wanted to solve with it in the first place: an element that has focus and that is unmounted.

1. Stealing the focus from iframes can be very frustrating. For instance, It seems to be a common use case to have a chatbot on a webpage. Or try working in codesandbox with the Dialog open, impossible 😆.
2. The 50ms interval doesn't leave any room for developers to understand that there is a trap focus. It's moving too quickly. I would be curious to try 500ms out (still enough for the users?). It would also reduce the "noise" for developers the interval introduces:

[eps1lon]

Closing this since it's been incomplete for over 7 days. While there are come inconveniences with trapping focus they're not on the level of a bug as far as we know.