176205 2017-08-31 17:36:04 -0700 On webkit ios there is now way for accounting for virtual keyboard height 2019-03-09 19:34:25 -0800 1 1 1 Unclassified WebKit DOM WebKit Nightly Build Unspecified Unspecified RESOLVED DUPLICATE 170982 P2 Normal --- 1 sam.saffron webkit-unassigned albertofdzm bugzilla j.jaffeux ph rniwa thorton wenson_hsieh oldest_to_newest 1344240 0 sam.saffron 2017-08-31 17:36:04 -0700 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. 1383043 1 sam.saffron 2017-12-18 20:14:26 -0800 Anything ideas here, window.height is bogus innerHeight bogus, there is pretty much no way of telling 1384859 2 j.jaffeux 2017-12-28 06:16:28 -0800 This issue is a major source of pain for any ambitious web only app, fixing it would greatly help people following this way. 1388780 3 ph 2018-01-12 06:11:04 -0800 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. 1413693 4 albertofdzm 2018-04-11 08:40:28 -0700 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. 1503261 5 lforschler 2019-02-06 09:18:51 -0800 Mass move bugs into the DOM component. 1512625 6 bugzilla 2019-03-05 06:17:45 -0800 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. 1512639 7 wenson_hsieh 2019-03-05 07:29:56 -0800 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. 1512647 8 bugzilla 2019-03-05 08:36:17 -0800 (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... 1512889 9 sam.saffron 2019-03-05 15:51:56 -0800 (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" 1514479 10 rniwa 2019-03-09 19:34:02 -0800 (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. 1514480 11 rniwa 2019-03-09 19:34:25 -0800 *** This bug has been marked as a duplicate of bug 170982 ***