Now there are a number of fixes that can correct the situation a little, but there is still no full-fledged working version.
For example, such methods are offered here: https://hackernoon.com/how-to-fix-the-ios-11-input-element-in-fixed-modals-bug-aaf66c7ba3f8
Possible solutions:
1. Setting a fixed position for the body tag
When opening a modal window, add the position: fixed style for the body tag, and after closing - delete it. However, if the modal window was not opened at the very top of the page, when it is closed, the page is shifted up (you can correct it by keeping the scrolling position when opening it and setting it when closing).
Minuses:
- When you close a modal window, the address bar and a tabbed panel appear, which is annoying (caused due to the JS positioning of the scroll).
- Strong offsets are removed, but on the input elements in the lower part of the modal window, a slight cursor offset still remains (the user can work in this case, but visually does not look very pleasant).
2. Translation of the display of a modal window with position: fixed to absolute.
The modal window is assigned the property position: absolute , dimensions and offset are calculated when it is created. This approach fundamentally eliminates the problem with the cursor shift, but has a number of unpleasant artifacts.
Minuses:
- On an iOS smartphone, when the keyboard is opened, the screen shifts to the center of the input element, which disables the scroll lock and the dark overlay does not completely cover the screen area.
- On a number of mobile devices, the bottom bright bar is not covered with dark overlay, even if the screen height is correctly calculated.
3. Translate all modal windows to individual pages
This approach is more radical, since implies completely rewriting for iOS all the code that is used in modal windows, but I see it most fully fixes the problem.
Minuses:
- It is necessary to completely remove the modal windows on iOS 11 and translate their contents into a regular page.