Height 100% on Webkit is treated as height behind virtual keyboard (regardless of virtual keyboard visibility). There appears to be no method of actually getting the height of the visual viewport. On Android you can create fixed panel with height 100% and it automatically sized to the visual viewport. This makes it significantly simpler to account for the virtual keyboard. In iOS it is very very hacky. I wish there was another mechanism of either getting the virtual keyboard visibility and height or setting height to actual visible viewport.
Anything ideas here, window.height is bogus innerHeight bogus, there is pretty much no way of telling
This issue is a major source of pain for any ambitious web only app, fixing it would greatly help people following this way.
This is a major problem for any web app that relies rich text input functionality. Trying to create a advanced chat experience using auto-scroll features seems nearly impossible for iOS 11. A similar issue for an open source rich text editor is documented here: https://github.com/ianstormtaylor/slate/issues/1513#issuecomment-356554052 We need a reliable way to determine the actual viewport of users here with correctly considers the on-screen keyboard on touch devices.
I have this same issue. Our whole app layout relies on html,body {height: 100%;} making it almost impossible to deal with this bug when the users need to use the keyboard.
Mass move bugs into the DOM component.
Is there any update on this? I'm having a similar issue and haven't found any solutions -- even hacky ones -- that mitigate this bug.
The visual viewport API should assist with this (see: https://bugs.webkit.org/show_bug.cgi?id=170982), but note that this is currently only enabled by default in trunk WebKit.
(In reply to Wenson Hsieh from comment #7) > The visual viewport API should assist with this (see: > https://bugs.webkit.org/show_bug.cgi?id=170982), but note that this is > currently only enabled by default in trunk WebKit. Thanks, Wenson! This looks promising. It works great with the virtual keyboard on Android but the real issue is iOS, so hopefully support comes there. My only concern is polling `window.innerHeight` on iOS doesn't provide any height difference with the keyboard open so I wonder if this would give correct numbers...
(In reply to Wenson Hsieh from comment #7) > The visual viewport API should assist with this (see: > https://bugs.webkit.org/show_bug.cgi?id=170982), but note that this is > currently only enabled by default in trunk WebKit. As soon as trunk is folded into an iOS beta I would be glad to test this. Let me know. I am also with @Sheng, I found `window.innerHeight` to be incredibly unreliable on current iOS. It sometimes works and changes, but sometimes it takes 10-20 seconds in polling every millisecond to change when virtual keyboard is expanded. Our current approach here is just to force users to tick a box that says "hey, I am using a physical keyboard on my iPad"
(In reply to Sam Saffron from comment #9) > (In reply to Wenson Hsieh from comment #7) > > The visual viewport API should assist with this (see: > > https://bugs.webkit.org/show_bug.cgi?id=170982), but note that this is > > currently only enabled by default in trunk WebKit. > > As soon as trunk is folded into an iOS beta I would be glad to test this. > Let me know. > > I am also with @Sheng, I found `window.innerHeight` to be incredibly > unreliable on current iOS. It sometimes works and changes, but sometimes it > takes 10-20 seconds in polling every millisecond to change when virtual > keyboard is expanded. > > Our current approach here is just to force users to tick a box that says > "hey, I am using a physical keyboard on my iPad" With visual viewport API, can just listen for "resize" event on window.visualViewport.
*** This bug has been marked as a duplicate of bug 170982 ***