I have a simple web app with a few text inputs and the inputs toward the bottom of the page get covered up by the iPhone keyboard. This is a terrible user experience making it difficult for the user to see what text they are entering as well as selecting other elements on the page after they are done entering text.
Apple documents the behavior here: https://developer.apple.com/library/archive/documentation/StringsTextFonts/Conceptual/TextAndWebiPhoneOS/KeyboardManagement/KeyboardManagement.html
I've seen several posts about this problem and there are multiple solutions for iOS app development but no real solutions for web apps.
I don't have the resources to test on multiple devices and I don't have an android device so I don't know if this problem even occurs there.
Is there a cross platform solution for detecting when a keyboard is covering the UI, how much of the UI is being covered, and an approach to ensure the input is visible?
This answer is a hack; but it's the best solution I have come up with.
Adding a padding to the bottom of the page that is large enough for the keyboard enables content to be displayed as desired when the keyboard is visible.
Using some javascript listeners and a CSS class, this padding can be added only when the keyboard is displayed.
body.keyboard {
height: calc(100% + 500px); /* add padding for keyboard */
}
The following javascript will add and remove the CSS class when an input has focus, which is the closest I can get to figuring out when the keyboard is displayed.
// focus events don't bubble, must use capture phase
document.body.addEventListener("focus", event => {
const target = event.target;
switch (target.tagName) {
case "INPUT":
case "TEXTAREA":
case "SELECT":
document.body.classList.add("keyboard");
}
}, true);
document.body.addEventListener("blur", () => {
document.body.classList.remove("keyboard");
}, true);
It's also worth noting that iOS performs an annoying zoom if the input font size is less that 16px so this is also important.
input {
font-size: 16px !important;
}
Please let me know if you have a better solution.
What about this: stackoverflow: Scroll textfield up when keyboard popsup?
Even if you're not using jquery you could still bind the focus event and scroll the page using the window.scrollTo(0, document.body.scrollHeight); function and just scroll to the bottom. Because interestingly, the space is created, but not scrolled to.
If you want to go fancy, you can check for the window size in order to determine if and how much you want to scroll.
What you can do is hide the keyboard on any click event. So, figure out when you don't want to display a keyboard and when do you really want to show it.
So once figured, you can hide the keyboard like:
InputMethodManager manager = getSystemService(INPUT_METHOD_SERVICE);
manager.hideSoftInputFromWindow(getCurrentFocus().getWindowToken(),InputMethodManager.HIDE_NOT_ALWAYS);
Here's an answer that might help you: Scroll textfield up when keyboard popsup
In summary, you can make use of the visual viewport api and update the next render accordingly.
What I did is to scroll the elements into view when focused by touch.
There is no exact api or anything to know if the keyboard is open at all, or how much the keyboard covers (in chrome actually the keyboard reduces the viewport, not overlays on top), but looking at average mobiles, it covers roughly half of it.
As for the implementation, I use a kind of simple heuristic. You can go all-in if the device is a touch device see mobile device detection section here, but this doesn't necessarily cover laptops with touch screens. (and doing it based on resolution is a bad idea also)
I took this "touch device" approach one step forward, and listen on the touchstart event on form elements and set a variable something like hasTouchKeyboard, and then scroll element to top of page (or at least first half that is likely not covered) when focused if this variable is true.
The idea behind it is that the touchstart usually fires before the focused event, plus the real differentiator is that if the user touched the input field, then it is 100% that it is using a touch device AND actually used touch on it (that will likely trigger the keyboard), and not just focused it with mouse on a hybrid device.
It is definitely not bulletproof, but fairly simple and works well without any user agent magic or other crazy stuff.
For www.lokilist.com I needed a solution that worked without javascript for the text input used to enter a Session ID.
On the server, I used the "isMobileDevice()" PHP function found here:
https://stackoverflow.com/a/23874239/20094562
Then attached a css class with onfocus css only if the requesting browser was "mobile" (that function considers tablets as mobile, which is all the better for this purpose since we actually care about touch screens).
To summarize:
Detect touch screens based on user agent with isMobileDevice()
In your css, include a placeholder class like ".mobileTextInput".
Also include in your css the onfocus property of that class like ".mobileTextInput:focus". This is what will reposition your text input when selected.
If the user agent is a mobile device, add the mobileTextInput class to the text elements you want to move above the virtual keyboard.
I've run into a glitch in chrome on iOS where "scrolling" the screen down after an input focus causes the keyboard to obscure the bottom part of the page and a user cannot scroll down to see the elements below (this is where I have a textarea). This happens only in the iOS Chrome browser, not safari.
I'm going to walk through the steps to try and make this as clear as possible.
A user focuses the textarea input. The behavior is as expected here: the keyboard pushes the screen up.
If the user doesn't scroll at all and taps out of the input then this behavior will continue the next time they focus in the textarea (keyboard pushes the entire screen up).
If the users drags the screen down to scroll up while the textarea is focused (no matter how little they "scroll") the screen has a snap-like effect and the keyboard covers the bottom of the content. This keyboard behavior is preserved...
the keyboard continues to cover the content this way each time the user taps in and out of the textarea.
The only way I have found to reset this effect is to pull the screen up when the textarea is not focused. This causes a little flicker effect and when the user clicks into the textarea the keyboard goes back to
I have "scrolling" in quotes because there is no actual scroll happening on the page as the height, body, and form are all 100% the height of the browser. The virtual keyboard really just pushes the viewport off the screen in the first scenario.
I made a video of the issue here: https://youtu.be/yD0tjMfy5I8
I can't find any information about why this is happening and I've not had any luck trying to style the form differently because (from what I can tell) there is no way to find the height of the visible area when the keyboard is opened (window.innerHeight doesn't work)
Has anyone found a way around this glitch?
When a user focuses on a text input, mobile browsers zoom in for convenience. This is good.
But on a single page app, you don't refresh the page upon the form being submitted, so the viewport doesn't return to its non-zoomed state. This makes it difficult for the user to get their bearings again, or navigate as they did before. It is possible for them to double tap, to return the viewport to normal, but many of our users wouldn't know to do that.
I believe I am asking the same thing as the following questions, none of which provide a reliable answer. I would strongly prefer not to have to include another JS library.
Mobile-friendly web design: How to programmatically zoom out after text input?
Mobile Viewport zoom back
I'm attempting to make my website tablet friendly and I'm facing a strange issue.
I am testing on an Android 4.0 tablet with Chrome 30.
I have a fixed modal popover screen. While this screen is on, we don't want to let the user scroll the background so touch events are prevented. However, in this window we have a scrollable area with overflow:scroll, therefore the touch event is not prevented if the touch start event is detected there. So far so good - Android responsibly scrolls the area as expected.
Problem is, if the user long-presses an element inside the scroll area for about half a second, and only then scrolls - the element where the touch started appears to be selected for a moment. That selection disappears after a bit. But, in case the user scrolls during that bit - the whole page scrolls instead of the scrollable area. It's as if the focus is changed. What's going on?
I tried to set CSS selection rules on the elements inside but it didn't help.
-webkit-touch-callout:none;
-webkit-user-select:none;
-khtml-user-select:none;
-moz-user-select:none;
-ms-user-select:none;
user-select:none;
Every other answer suggests to prevent the touch event which I can't because it's meant to be scrolled. Any ideas what's causing this?
OK, I got it.
Add cursor:default!important to the above CSS rules.
I DID come across such a solution but it failed on first try. In my case, the specificity of elements inside the scrollable area was too strong, rendering cursor:default useless and I didn't realize it. I apply this only to mobile devices by detecting the useragent, therefore I can afford dismissing the previous cursor attribute with !important as it won't affect any desktop clients. Sweet!
Still not sure why this worked. If anyone could supply information on how the cursor attribute affects Chrome on Android I will be grateful.
My webpage is a form with many text boxes. I have created my own popup keyboard which is much smaller than the iPad one thereby saving a lot of screen real estate, especially in Landscape mode.
My problem is that when I select a text box for entry the iPad keyboard appears.
Is there anyway through JavaScript to hide and disable the iPad keyboard.
Thanks,
Not to put your idea down in any way, honest. It's bad practice generally to try and 'supplant' the user's device for several reasons.
They might have a special keyboard tailored the way they want.
Their device might be in chinese, japanese, etc.
It's better to let the device itself handle this. In most devices there is absolutely no way to disable the default keyboard.
Problems I can see, besides the above ones are, what happens in devices that are 'mobile' but have a physical keyboard? Like the windows tablets. Do you account for different languages? All of them? Do you provide a way to switch between them? Can you set a default language so user's don't ALWAYS have to switch?
I'd suggest not using your own popup keyboard. Let the device handle it.
Also, check out UX Stackexchange and ask for some input there. They'll have better suggestions.