I have an unusual problem with my Android app. Whenever I focus an input field on a webpage, the soft keyboard appears and immediately disappears.
The app integrates Crosswalk for the browser functionality, though I want to say this used to happen when I used WebView previously.
This is a screen recording of the problem:
It seems to be pushing up or resizing the HTML to accommodate the soft keyboard, but failing for some reason.
Does anyone know why this happens and more importantly, know how to fix it?
EDIT: I've found that if I add android:windowSoftInputMode="adjustPan" to my AndroidManifest.xml file, the problem does not happen. Setting it to "adjustResize" makes it always happen.
Would still love some help if anyone knows the answer :)
The solution to this is a workaround to an Android quirk (of which there are many). From what I've read, this does not happen on iOS, but I have not tested it to confirm.
The problem is when the soft keyboard appears, it triggers a window resize. When you are working with a responsive website, as I am, you are likely to have code that handles resizing. When the keyboard appears, a window resize occurs and the keyboard disappears due to custom resize code.
Solution 1:
The solution is to rewrite resize events to be orientationchange events. While this isn't an ideal situation, if an app is the only target, then it should be fine.
To clarify, change from (using jQuery):
$(window).resize (function ()
{
// Code on resize
});
Change to (using jQuery):
$(window).bind ('orientationchange', function ()
{
// Code on screen rotation
});
I am not sure of the browser support for orientationchange since it's not available on http://caniuse.com, but I can say that it does work with the current version of Crosswalk (19.49.514.4).
Solution 2:
An alternative solution suggested by chrisdew at https://stackoverflow.com/a/9229672/3509051 suggests "adding a listener to the input's focus event which disables reacting to resize events for 0.5s.". This should also work if you are happy to have a 0.5s delay whenever an input is focused.
Related
I have a responsive web page that I want to reorder with jquery when going from one size to a smaller one. Everything is great except when I reorder an element (a DIV, for example) that has an input in it, like the search form:
$( '#searchfrm' ).insertAfter( '#bodyfrm' );
If I do this, when I click the input, the keyboard appears for a second and then disappears. This happens only on Android, on iPhone it works perfectly.
If I comment the code line, the input works perfectly on Android but I don't want the search form on top, but on the bottom of the page on the responsive design.
How do I prevent this from happening? Thanks!
I found that the problem was when reordering the elements. The reordering process was being done all the time so, in Android, when the keyboard appeared, jquery was reordering again, making the keyboard disappear. The solution was adding a variable in jquery to prevent the reordering process all the time and do it only once when going from 1024 to 700, for example.
I had a similar issue but found it was due to the $(window).on("resize",function(){...}); and not the .insertAfter script used to reposition the element.
If the element you reposition has an input field and that input field is in focus ~ the default behavior of Android opening the keyboard actually resizes the browser causing the function to loop. - REFERENCE: (dealing-androids-constant-browser-resizing). Changing the function to trigger on (load) as opposed to (resize) did the trick for me. $(window).on("load",function(){...});
As many do , I ran into the problem of the softinput covering my send buttons so I did some searching and found the accepted way of fixing this issue is "android:windowSoftInputMode="stateAlwaysHidden|adjustPan"
and this works great on my device, but when I try it on my girlfriends phone it doesnt work. I see the dialog lift a little before the input shows up on screen , but not much and the send button is still covered. Why would this work on some devices , but not all?
Messing with the onscreen keyboard is difficult at best because on the one hand:
It's supposed to be where it is, that way users expect it, it's consistent, very important in UI design
BUT
It can get in the way.
The solution (based on the Android design guidelines, experience and feedback and so forth) is not to faff with it too much, you can have basically the following kinds of behavior:
*Pops up when activity starts (which happens if the activity has an input)
*Doesn't pop up when activity starts (despite the first input having focus <-- good) but will when the user taps.
It's good to dismiss the keyboard when the user is done, that is have the "enter button" take them to the next entry, if there's none left, hide it, if it's some sort of data capture form that validate as they go along, if not don't do this because they might press back in an attempt to get it up.
Addendum I
"adjustResize"
The activity's main window is always resized to make room for the soft keyboard on screen.
"adjustPan"
The activity's main window is not resized to make room for the soft keyboard. Rather, the contents of the window are automatically panned so that the current focus is never obscured by the keyboard and users can always see what they are typing. This is generally less desirable than resizing, because the user may need to close the soft keyboard to get at and interact with obscured parts of the window.
From the documentation here: http://developer.android.com/guide/topics/manifest/activity-element.html
Difference between adjustResize and adjustPan in android?
See there for more.
It's difficult to pan correctly because the layout of the activity can be many things, it could scroll to the left, it could all be relative, it's not one strip where it need only jump up and down, some things also have more than one solution, more than one way to pan so it is visible. You haven't really described what doesn't work btw. I'm trying to explain the issues of what I think you want.
Does this help?
Suddenly got here. You shouldn't mix several values inside android:windowSoftInputMode="" attribute. So, you can preserve android:windowSoftInputMode="adjustPan" and hide a keyboard with hideKeyboard() (look for this method in the Net). Probably you can add listeners to hide it everywhere inside the activity.
I have an Android app using PhoneGap 1.6 and Sencha Touch 1.1.1. One view has a text input field which behaves oddly in Android: it duplicates itself and it is very difficult to remove focus.
I have determined that it is a WebTextView coming up over top of the "real" input field. The problem I am having with this is that blurring the text field with screen taps is extremely difficult, and if you scroll the parent container, the WebTextView does not scroll with it, so you can see both at the same time.
The only way to remove focus on the element is to tap furiously all over parts of the screen, much like triggering the frustration detector from Mavis Beacon.
My actual question is: how can I turn off this functionality completely, or at least work around it? It is not reasonable to expect the user to do anything other than single-tap outside of the box, or press the Back button on the device to stop input in the text field. As it is, pressing Back simply stows the soft keyboard and does not give up focus.
These are browser bugs, triggered by some CSS-flags.
To explain the bug:
The device creates some kind of "screenshot" from the web-sites content. All transformations and transitions are made on top of the "screenshots" from the actual page.
If you have input elements, there will be some kind of proxy elements rendered on top of the "screenshot". Sometimes the are these proxy-elements at the wrong position.
This happens, if you trigger the website to be hardware-accelerted. You have to drop some CSS-definitions:
transform(), translate(), transform3d(), translate3d().
The Bad news are:
You cannot solve this problem, because it a bug within the browser.
I have some different android devices, all have different problems, one fix will break another device.
I think the bug will never be solved, because noone cares about the embedded browser since android 4.1 and the chrome.
If you can disble hardware accelertion, this may help.
The good news are:
There are rumors about an embeddable chrome-webview.
I started to write some blogposts about "the new IE":
http://christian-kuetbach.de/blog/post/14
When you have some clickable content like <a>, <input> or <area> and before this you have an absolutely positioned element with a bigger z-index, there is the wrong behavior of 'click-through'.
I click on the area where the clickable element is behind the front element. In other browsers there is the right behavior that the click does not go through the front element. But only in Android Browser you can click through the front element and activate the element behind. This is a known bug and you cannot avoid it. It's even in newer versions (I test on 2.3.3 in the official Android emulator).
There are some workarounds described in some forums but none of them worked for me.
I tried to put an <iframe> or an <a> between front and back
I tried to change the DOM so maybe the browsers state is refreshed
I tried to have the back elements be positioned as well
None worked
I'm especially having problems with the image map's area elements.
Has anyone had the same issue and managed to work around it?
I'm specifically interested in solutions which are tested against image maps.
I am wondering about a few things here. First, what is the purpose of having an overlaid image and using the image maps? I see you're including jQuery - can you use the hover event with jQuery to change the orientation of the images and do the swap? What about attaching to the click event for the image map, and checking to see if the lightbox is open. If it is, then return false;.
Just trying to think out loud. Sometimes another take on it can be helpful.
This is a quick blindfolded reply, so let me know if I should expand/fix it further. The general idea being a CSS class for both the hover and focus events that disables pointer interaction.
yourElementClass:focus, yourElementClass:hover {
pointer-events: none;
}
Actually I've managed to avoid it by moving the objects below to let them be not visible.
But in cases similar to yours the only workaround that actually works is to manage all the clicks in jquery (especially the ones on the background) and to bind/unbind the clicks events on needs.
there are also some things that could help on some version/mobiles (but do not solve the problem)
the above item has background:rgba(0,0,0,0.1);
you should put a gif or png as background of the above element (as well as the background color as point 1)
using thouchstart instead of click as bind event sometimes helps.
the actual version of android/browser are not affected with this bug (or at least it never happen to me) but it could be nice to know the affected versions. If someone has a list.
I have an app that runs fullscreen by using:
getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,WindowManager.LayoutParams.FLAG_FULLSCREEN);
Because of this the layout, android:windowSoftInputMode="adjustResize" is not working properly, i.e. it dose not resize.
Is there any way to get over the problem?
FYI: This is an existing AOSP (Android Open Source Project) bug: http://code.google.com/p/android/issues/detail?id=5497
Ideally this bug would be fixed, but until then here are a couple thoughts of how it could be worked around. Since I have no idea what application scenario this pertains to, these may not be very applicable.
In agreement with my best interpretation of the previous answer, design your layout so that adjustPan works ok with it. The first thing I can think of here is not having any headers or footers that are intended to remain on screen when the keyboard is up.
Don't use FLAG_FULLSCREEN with a layout that can accept text input. Possibly it wouldn't be a big deal to show the status bar when accepting input. However, for something that views content with embedded input fields (like a web browser) that has a fullscreen mode, this doesn't make much sense at all.
Implement adjustResize-like behavior of your own. I'm not sure how well this would work, but possibly you could write a subclass of whichever class is causing the keyboard to be shown (ex: EditText) where you either track when the keyboard is shown or take over the calls to show and hide the keyboard (overriding at least onKeyUp and onTouchEvent). When shown, resize your content - possibly with a best guess of the softinput height, since users can install different soft input methods. I believe this would be technically difficult and not reasonable to attempt without extreme need.
Instead of android:windowSoftInputMode="adjustResize" you can try with android:windowSoftInputMode="adjustPan"