Get viewport height when soft keyboard is on

Question

I\'ve been trying to make this work for days now, with no luck, so I thought I\'d share info and maybe someone comes up with a solution.

I want to get the exact viewport

Answer 1

The viewport dimensions come from the size of the UIWebView element.

As mentioned in the previous answer there are two ways to handle adapting to the on screen keyboard. You can resize the view or adjust the content insets.

The dimensions of the viewport on iOS are reporting the size of the view so resizing would adjust the viewport. Safari adjusts the insets and keeps the view the same size so the viewport does not change.

If you were to make assumptions that touch devices generally utilize on screen input rather than external keyboards you can programmatically adjust the size on your own by taking the device height or width depending on orientation and factor in a multiplier for portion of the screen consumed by the on screen keyboard.

I utilize a viewport class to act as a proxy to give me most likely real viewport dimensions rather than browser reported and binds to input elements to track state of input elements and orientation changes to dynamically modify the multiplier applied when requesting the viewport dimensions.

Answer 2

I've found myself with the same problem and after a while mixing CSS and a little bit of javascript, I found a solution.

Notes:

• I used jQuery and SCSS
• I preferred to hide the element instead of changing its position (simple and effective)
• The element is shown if the virtual keyboard is closed but the input is still on focus. For this I wrapped the css rule in a media query @media screen and (min-aspect-ratio: 11/16). 11/16 because it's less than the common 9/16 ratio (the presence of the virtual keyboard increases this ratio then the rule is applied)

The solution:

First, the script (using jQuery):

$(document).on('focus', 'input, textarea', function(){
    $('body').addClass("fixfixed");
});

$(document).on('blur', 'input, textarea', function(){
    $('body').removeClass("fixfixed");
});

So, while the user focuses on a text input and the virtual keyboard is open, the body has a 'fixfixed' class.

Then, the CSS (I'm using SCSS):

.fixfixed{
  @media screen and (min-aspect-ratio: 11/16) {
    .bottomThingToHideWhenVirtualKeyboardIsShown{
      opacity: 0;
      pointer-events: none;
    }
  }
}

And that's it!

Hope it helps someone!

Answer 3

I came up with this hack:

var storedWidth = 0;
var storedHheight = 0;

function onResize() {

  var windowWidth = $(window).width();
  var windowHeight = $(window).height();
  var screenWidth = screen.width || windowWidth;
  var screenHeight = screen.height || windowHeight;
  var width, height;

  if(screenWidth < screenHeight) {
    if(windowWidth > storedWidth) storedWidth = windowWidth;
    if(windowHeight > storedHeight) storedHeight = windowHeight;
    width = storedWidth;
    height = storedHeight;
  }else {
    width = windowWidth;
    height = windowHeight;
  }

  //use width and height from here

}

Now this would fail in two cases:

• screen.width/screen.height not being supported; it would fallback to the erroneous jquery dimensions. In my case, the soft keyboard made the height smaller than the width while in portrait mode, so the jQuery dimensions resulted in a false landscape mode and thus showing the 'rotate your device' message.

• the page is opened with the soft keyboard opened, which I think is moot. Also after hiding it, the largest height is stored so things will be fixed after that.

Note:

• window.innerWidth/window.innerHeight could be used to ditch the jQuery dependency

• above code is to fix the keyboard issue in portrait mode, but same solution could be used for landscape mode

Answer 4

Just to give you an idea, when the keyboard appears on iOS by default it does nothing on the underlying scrollview.

If your content is shown in a custom UIWebView, it is up to the programmer to either:

• Resize the scrollview to avoid getting unreachable content under the keyboard.

• Adjust the scrollview's content insets (recommended). The scrollview size stays the same but a "border" is added to the bottom so the user can scroll all to all the contents.

I am not sure how either solution affects the viewport, but your could try both.

If your web content is being presented by Safari however, Apple adjusts the insets for you.

Answer 5

This solution is a bit convoluted, but it might work...

1. Detect whether or not the keyboard is active.
2. Grab the viewport width/height
3. Subtract the height of the keyboard.

Answer 6

In the view I wanted to take the height of the remaining screen after the virtual keyboard was on, I was using an absolutely overflown element that covered the whole screen using screen height and the content of the whole page was inside of it. As a result, the virtual keyboard was opening on TOP of the overflown element, without changing its dimensions.

To fix the specific problem, all I had was change the position of this element to static and remove the overflow when the virtual keyboard was opened - actually ios changes to THIS behaviour by default when issuing he virtual keyboard (changes elements to static position) and this is why the fixed elements become static.

I hope this helps.