Closed michalkvasnicak closed 4 years ago
First, problem with scroll is because we don't set up the targetElement
correctly. This one can be fixed by allowing to scroll children of a targetElement using allowTouchMove
with a function.
The second problem where a part of Popover is hidden behind virtual keyboard will be tricky. We need to subtract from available space height on iOS?
This can be achieved now using VisualViewport
but the polyfill is necessary because on iOS it is supported only from version 13.
Or maybe just use some constants that'll be used if page is scrolled so we will subtract from available height the "size" of keyboard and chrome bar on iOS? And use VisualViewport
where available because even polyfill from https://github.com/WICG/visual-viewport does not work on iOS.
We need to take into consideration that in cases where the focus is not on input elements then we don't want to subtract the virtual keyboard.
We can detect the change in height when scrolling. This can be used to detect correct viewport size when scrolling. But if you have an element with focus, that causes keyboard to open it's undetectable and we can resort only to detect whether the focused element accepts user input.
Maybe we could detect the sizes using height: -webkit-fill-available
on iOS where VisibleViewport
is not available and using 100vh on other browsers that doesn't have this API too? Maybe this solution could cover all the browsers?
I've implemented a fix but on iOS < 13 I strongly recommend to allow body scroll if Popover is open (Autocomplete, Select, Menu, ...) because on mobile, focused input is scrolled into view so it's in the middle but there is no event to detect this behaviour. On iOS 13 it's handled properly.
Sources:
If you expand
Select
on iOS device, virtual keyboard will appear but the menu is underneath the virtual keyboard.