iOS keyboard covers inputs when using useDialog/useModalOverlay

[JRS-Developer]

Additional information: #6405 shows that this is not only limited to full screen dialogs, but modal experiences in general.

Provide a general summary of the issue here

we noticed that using the example from https://react-spectrum.adobe.com/react-aria/useDialog.html causes issues when creating a full screen dialog where an input is at the bottom of the dialog, it's impossible to see the input, the keyboard covers it, it only happens on iOS, old and new safari versions. we tried using radix dialog and it works properly so it seems some internal logic of react-aria.

Screen.Recording.2024-02-22.at.2.16.30.PM.mov

🤔 Expected Behavior?

the dialog should leave the browser to focus the input and "fix" by itself the keyboard covering.

😯 Current Behavior

the keyboard covers the input and it's impossible to scroll down, the dialog scrolls up when trying it.

💁 Possible Solution

no sure

🔦 Context

No response

🖥️ Steps to Reproduce

1. Open this codesandbox, it uses react aria and radix, same styling.
2. Click on Open React aria dialog and select input at the bottom of the dialog and the keyboard will cover the input and it won't zoom correctly.
3. Try the same with Radix and it won't happen

Version

3.32.1

What browsers are you seeing the problem on?

Safari

If other, please specify.

No response

What operating system are you using?

iOS

🧢 Your Company/Team

No response

🕷 Tracking Issue

No response

[LFDanLu]

Since you are using a hook implementation, you'll probably want to use useViewportSize to determine the height of your modal for cases like these. Alternatively, you could use React Aria Components for your Modal which will provide the viewport's size, see https://react-spectrum.adobe.com/react-aria/Modal.html#modaloverlay

[JRS-Developer]

Use the height of the modal for? Could you explain more? @LFDanLu

[LFDanLu]

@JRS-Developer since the virtual keyboard takes up space in the viewport, you can set the height of your fullscreen modal to match the height of the the visual viewport and thus have it adapt to when the virtual keyboard is open. You can see this in action with the edit modal in the first Table example on the React Aria home page. The style in question:

react-spectrum/packages/dev/docs/pages/react-aria/home/ExampleApp.tsx

Line 488 in fa3862e

fixed top-0 left-0 w-full h-[--visual-viewport-height] isolate z-20 bg-black/[15%] flex items-center justify-center p-4 text-center backdrop-blur-lg

[JRS-Developer]

Hello @LFDanLu, will this work in cases where the modal is bigger that the mobile screen? Like an modal that overflows? Like the scroll=body of Mui? https://mui.com/material-ui/react-dialog/#scrolling-long-content

[LFDanLu]

The scroll=body case shown for material-ui probably wouldn't work since the strategy I suggested above is to make sure that the modal's height is equal to the visual viewport's height and to make the body of the modal scroll instead.

[JRS-Developer]

@LFDanLu Yeah, we use a lot dialogs that work like the scroll=body and it's pretty anoying for IOS users

[LFDanLu]

I would need to dig further into what radix is doing vs our implementation, but it honestly feels to me to be a pretty odd experience in that case too. From your video, the virtual keyboard still covers the textfield when opened until after some delay (not sure what caused it to scroll into view). If an additional interaction was required to make the input scroll into view after the virtual keyboard opened then that feels less than ideal. With the example in the React Aria home page, the modal shrinks and the input remains in view:

Screen.Recording.2024-02-27.at.11.50.42.AM.mov

[JRS-Developer]

Hello, I updated the example with a really simple dialog without any library and it works as radix, it's really an issue with react-aria, here is the video using all dialogs including the simple one

Screen.Recording.2024-02-27.at.3.12.15.PM.mov

[JRS-Developer]

Maybe some logic inside Overlay or useModalOverlay, no really sure

[LFDanLu]

It seems to be due to something in our preventScroll code for iOS Safari specifically, getting rid of that makes it behave like the native dialog that you shared. That code was written originally to prevent people from scrolling the background element beneath the Modal's underlay when the Modal is open so maybe we can get away with not enabling that behavior when the modal being used is a full screen modal that doesn't have a underlay. However, there could be a case where you have a very tall modal that still have an underlay visible that we will still need to solve for here. I've tried locally tearing out bits and pieces of that code but no luck so this will likely need a deeper dive since the fix itself was something hacky to work around mobile Safari quirks. All in all though, this code and much of our other modal specific code was developed with the contents of the modal being scrollable and the height of the modal itself never exceeding the visual viewport's height...

[LFDanLu]

For whoever picks up this bug in the future, note that the same issue can exhibit itself for our fullscreen modal dialog in RSP as well, looks like either an issue with the scrollIntoView code calculation or a race condition between when the scrollIntoView code calls itself and when the modal adjusts its own height to match the new visual viewport height

[IonelLupu]

I also tested in a simulator and even if it's not similar to a real device, there is some similar behaviour between the two. Focusing on date elements in the date selector makes the UI jump up and down as seen in the last part of the video:

Screen.Recording.2024-05-07.at.00.37.55.mov

[brianudensi]

Similar issue is also observed when using the useModalOverlay hook to create a modal. As seen here

[brianudensi]

@LFDanLu thanks for the swift response, just curious on when we should be looking out for an update regarding this issue?

[LFDanLu]

Hard for me to say, the team is pretty booked for the next couple of sprints, but I can see about bring this up in our next planning session and see if we can get it slotted in. Any help investigating solutions is welcome!