[react-aria/useButton] Modal close button clicks button behind (Android)

[saraC15]

🐛 Bug Report

On Android when a close button using useButton is clicked in a modal, and another button not using react-aria is behind, the button behind is clicked when the close button has closed the modal.

🤔 Expected Behavior

When clicking the react aria button that closes a modal, the button behind should not be clicked.

😯 Current Behavior

When closing a modal with a button using useButton the click will then also click on the button behind in case that it is a regular button.

Example:
https://user-images.githubusercontent.com/17428699/121678735-d5d0f800-cab7-11eb-94db-f53c53f78976.mov

Reproduce

• Go to https://irwe1.csb.app/ on an Android device or using the mobile emulator in your browser (can be reproduced both on chrome and firefox)
• Click on the button "Open with regular button"
• Click on the first button "Close with React aria button"
• You will notice that the modal closes and then quickly opens again.

💁 Possible Solution

Not a solution but it might to be due to both a 'touch' and 'virtual' pointer event being sent with a slight delay. When having a button using usePress behind you can see that the pointerType of the second click is virtual.

🔦 Context

Found this behaviour when introducing our component library that is built based on react-aria to an older platform, where we noticed our modals did not work on Android.

In the example case the button behind opens the modal again, but there could also be another button that happens to be behind the close button of the modal.

💻 Code Sample

Sandbox: https://codesandbox.io/s/little-smoke-irwe1?file=/src/App.js

🌍 Your Environment

Software	Version(s)
react-spectrum	react-aria button 3.2.2
Browser	Chrome 91, Firefox 89
Operating System	Android 11

Can also be reproduced using the mobile emulator in your browser (can be reproduced both on chrome and firefox)

🧢 Your Company/Team

🕷 Tracking Issue (optional)

[snowystinger]

thanks for reporting!
I think this is a duplicate of #1513 since it's fixed in the nightly, then it's a dupe of #1810 not the one i mentioned before

[devongovett]

Appears to be fixed in the latest nightly? https://codesandbox.io/s/agitated-oskar-7ntyv?file=/src/App.js

[saraC15]

Thanks for your swift replies!

@snowystinger I'm not sure if those are the same, this is Android specific and the other seem to be on other devices too.

@devongovett Unfortunately it seems to still be broken in the condesandbox you supplied with the updated packages.

To clarity this bug can only be reproduced on Chrome and Firefox when using the mobile emulators, aside from that it's Android only.

[snowystinger]

I followed the instructions on the chrome mobile (responsive) emulator. It's the same issue as the first one I linked, #1513

You can verify this by clicking on that first button the modal where your click is over the button in the background vs clicking on the same button where the big background button is NOT under where you click.

Unfortunately, it's a browser bug that we don't have a good solution for. However, if you usePress for that background button, you should be fine. It's only when you use onClick that there is an issue. The click is not fired on the same element that started all the pointer/mouse/touch events because it's removed during one of those events, click is then fired last, but since the original element isn't there anymore, it does whatever browser hit detection and fires it on the visible element at that coordinate. I'm going to close this issue since we have this covered in the other issue. Feel free to star/upvote the bugs we've logged against the browsers
https://bugs.chromium.org/p/chromium/issues/detail?id=1150073
https://bugzilla.mozilla.org/show_bug.cgi?id=1692033