I'm developing an Android application that uses a WebView to display the login page for Facebook. The page loads beautifully, and I'm able to select the username/password textboxes, but typing in them will not work. That is, they definitely have input focus (they have the orange focus highlight box and a flashing cursor), but typing in them does absolutely nothing. I'm not certain, but I think maybe the form buttons are also playing up - they appear to be simply refreshing the page, rather than submitting the form.
Just to be clear, although I'm particularly interested in getting Facebook running, I'm sure that this isn't a Facebook issue since other websites (Google, etc) also display the same behavior.
Does anyone have any ideas what might be the issue?
Turns out that it was apparently the WebView not having focus that was the issue.
I discovered that using the arrow keys to get focus on the textboxes caused them to work, so I theorised that there was an issue somewhere with something not having focus, most likely the WebView not having focus. Sure enough, adding the following line seemed to fix the problem:
webView.requestFocus(View.FOCUS_DOWN);
I'm still at a loss to explain exactly why the issue occurred in the first place - the textboxes should work whether they receive focus from being tapped upon or through being "arrowed" to - but at least I have a solution that appears to work.
Thanks for your input wf.
#Mac Does this single line :
webView.requestFocus(View.FOCUS_DOWN);
solved your problem ? I didn't in my case ,but this does :
mWebView.setOnTouchListener(new View.OnTouchListener() {
#Override
public boolean onTouch(View v, MotionEvent event) {
switch (event.getAction()) {
case MotionEvent.ACTION_DOWN:
case MotionEvent.ACTION_UP:
if (!v.hasFocus()) {
v.requestFocus();
}
break;
}
return false;
}
});
just for your referrence.
These are most have
webview.getSettings().setJavaScriptEnabled(true);
webview.getSettings().setUseWideViewPort(true);
webview.requestFocus(View.FOCUS_DOWN);
and if still not working then use one alternative below
Alternative 1
webview.setOnTouchListener(new View.OnTouchListener() {
#Override
public boolean onTouch(View v, MotionEvent event) {
switch (event.getAction()) {
case MotionEvent.ACTION_DOWN:
case MotionEvent.ACTION_UP:
if (!v.hasFocus()) {
v.requestFocus();
}
break;
}
return false;
}
});
Alternative 2
webview.setOnTouchListener(new View.OnTouchListener() {
#Override
public boolean onTouch(View v, MotionEvent event) {
switch (event.getAction()) {
case MotionEvent.ACTION_DOWN:
case MotionEvent.ACTION_UP:
v.requestFocusFromTouch();
break;
}
return false;
}
});
I don't know my case is exactly same as yours,
I found that add one css line can solve problem.
I just add
input{
-webkit-user-select: text;
}
to my css, then problem solved!
I'm sorry to say that none of this worked for me. I guess this depends on your context. In my case, the problem occurred within a html pop up (absolute div). All the other input field were doing ok.
Breaking down the problem I found out it's a bug in the webview. Fixed positioned divs containing other fixed/absolute position divs break input fields in the page. Hence a rule I worded for you (don't hesitate to reformulate):
If in your page you've got a fixed positioned div with none-default positioned nested divs (i.e. absolute, fixed, etc.), any of the following absolute positioned div in your page containing input fields will get the unexpected behaviour.
So, put your input fields at the top of the page (if you can) or avoid absolute divs nested in other fixed/absolute divs. That should help.
I posted something about it on my blog if you need more explanations and potential workarounds: http://java-cerise.blogspot.com/2012/02/android-web-view-inputfields-refuse-to.html
In my case TabHost from a previous fragment in back stack was stealing the focus from WebView input on every key press. Here's how I fixed it:
tabHost.addOnAttachStateChangeListener(new OnAttachStateChangeListener() {
#Override
public void onViewDetachedFromWindow(View v) {}
#Override
public void onViewAttachedToWindow(View v) {
tabHost.getViewTreeObserver().removeOnTouchModeChangeListener(tabHost);
}
});
See https://code.google.com/p/android/issues/detail?id=2516 for more on the topic.
Not sure if it's the problem since other websites also display the same behavior, but have you enabled javascript? A WebView does not enable it by default.
WebView webView = (WebView)findViewById(R.id.yourWebView);
webView.getSettings().setJavaScriptEnabled(true);
I spend a lot of time to solve this problem. Finally, I realized that it is not about WebView. In my case, I have a webview inside dialog. I want to handle back pressed button to cancel dialog and finish activity as well. And I wrote code below:
private void setOnBackPressed() {
this.setOnKeyListener(new OnKeyListener() {
#Override
public boolean onKey(DialogInterface dialog, int keyCode, KeyEvent event) {
if (keyCode == KeyEvent.KEYCODE_BACK) {
dialog.dismiss();
activity.finish();
}
return true;
}
});
}
So, when I use the keyboard, this method reject all key presses somehow and then it doesn't appear on the text fields.
I only changed the return value to false. So, it worked properly.
Hope it helps!!
PS: this method is inside my dialog class that extends Dialog class
I tried all the other solutions posted here, none of which worked.
Instead, I extended the WebView and overrode the InputConnection which forced KeyEvents to dispatch.
#Override
public InputConnection onCreateInputConnection(EditorInfo outAttrs) {
return new BaseInputConnection(this, false);
}
I encountered this problem because I am displaying a splash image while the webview is loading the first page. I am setting the webview to View.VISIBLE in onPageFinished, however despite being able to focus text boxes you can't type into them. I too can confirm that the fix to set the webview requestFocus to View.FOCUS_DOWN works.
NB. If I set the webview to View.VISIBLE in onResume the problem does not present itself but in my case the splash image disapears too soon.
It was happened to me loading a page in 4.1.2 and 4.2.2 and after one day of searching, I found the answer here (comment #18)
Quote from the original post:
Some of the various web pages I was rendering with WebView didn't fit properly into the WebView and as a result a div (or some other html component ) were being invisibly laid over the input fields. Although the input fields appeared selected when touched, they would not allow text input (even if i did manage to get the soft keyboard up using the track ball).
So the solution.
webview.getSettings().setUseWideViewPort(true);
This won't completely stop the issue, but makes the view more like a PC browser which sites are designed for. Less change of the overlay.
I found a problem that might be different, but it sounds similar. In the android 2.3 native browser, if you have fixed position elements on the page, it sometimes breaks select boxes.
A workaround for this problem for 2.3 devices is to never allow empty child elements for a fixed position parent. Thus,
<div style="position:fixed">
<div>
<span>not empty</span>
<span></span>
</div>
</div>
would become
<div style="position:fixed">
<div>
<span>not empty</span>
<span> </span>
</div>
</div>
This fixed my problem.
Don't know if this was the issue for your problem, and this is over a year after-the-fact, but figured I would share, as I'm currently dealing with another fixed postion issue on an app, and I haven't found a workaround for it.
I faced with similar problem, that text inputs doesn't work on webview. When you focus on text input it shows keyboard, but you cannot type any characters.
After a long search for solution, I found that this fixes the problem:
body {
-webkit-transform: translate3d(0,0,0);
-moz-transform: translate3d(0,0,0);
-ms-transform: translate3d(0,0,0);
-o-transform: translate3d(0,0,0);
transform: translate3d(0,0,0);
}
As I understood, this rule makes some devices run their hardware acceleration.
More information about translate3d(0,0,0) here.
On the other hand, according to this article it is not recommended to use GPU acceleration everywhere.
in my context (webview containing an external URL), this fragment works:
webview.setOnTouchListener(new View.OnTouchListener() {
#Override
public boolean onTouch(View v, MotionEvent event) {
switch (event.getAction()) {
case MotionEvent.ACTION_DOWN:
case MotionEvent.ACTION_UP:
v.requestFocusFromTouch();
break;
}
return false;
}
});
the error is because at every touch the webview was losing the focus!
By default, In Android, Webview allow user input with basic configurations:-
android:focusable="true"
android:focusableInTouchMode="true"
& enabled JavaScript but make sure there is not any activity/fragment level focusability blockage, in my case
android:descendantFocusability="blocksDescendants"
just removed this, worked for me. So cross-check such cases & fix them accordingly.
If we are dealing with EditText in WebView, then v.requestFocusFromTouch () will not work if we have to USER_AGENT written Mozilla / 5.0 (X11; Linux i686) and will work fine if Mozilla / 5.0 (X11; Linux x86_64).
It also happened in my project. I tried all above methods, none of them can effective. Finally, I solved this problem by use a dialog theme activity replaced the native Dialog. Hope this can help someone!
Related
I have not been able to replicate this, but is anyone aware of what might cause the entire screen on an Android device to go light blue? It seems related to selecting a radio buttons and then scrolling. It happens on Nexus 5x with Android 8.
Here is what it looks like:
I have only heard of one other instance of this occurring. Could it be device specific? Strangely enough, once it happens it seem to stay this way, though the user says it is somewhat intermittent.
Update:
This only seems to happen on Android 8, if that helps anyone...
So, I eventually found the offending code. I verified this is only happening on Android 8 devices, maybe only Samsung? The offending code was:
mFormScrollView.setDescendantFocusability(ViewGroup.FOCUS_BEFORE_DESCENDANTS);
mFormScrollView.setFocusable(true);
mFormScrollView.setFocusableInTouchMode(true);
// Hide the keyboard when moving the screen up or down. This should only
// be an issue when
// on a text edit field. Also disable focus jump using
// "requestFocusFromTouch"
mFormScrollView.setOnTouchListener(new OnTouchListener() {
public boolean onTouch(View view, MotionEvent event) {
if (event.getAction() == MotionEvent.ACTION_UP || event.getAction() == MotionEvent.ACTION_DOWN) {
Utilities.hideKeyBoard(FormActivity.this, view);
}
// Keeps screen from jumping to nearest EditText
// view.requestFocusFromTouch();
return false;
}
});
The offending line is commented out - the view.requestFocusFromTouch() method, which was meant to keep the screen from auto jumping to the next text field when the keyboard was hidden and focus lost. On Android 8 this is not happening, but I need to verify with older versions.
We have android hybrid app with Cordova where are creating custom inappbrowser with cordova webview to show the content. In Android lollipop devices, when user selects input field, keyboard pops up and user can enter test but there is no curser in the input field. This is not happening in pre lollipop. I tried below options, also this happens sporadically, i am getting focus sometimes but most times it is not working
inAppWebView.getSettings().setJavaScriptEnabled(true);
inAppWebView.requestFocus(View.FOCUSABLES_TOUCH_MODE);
or
inAppWebView.requestFocus(View.FOCUSABLES_ALL);
or
inAppWebView.requestFocus(View.FOCUS_DOWN);
or
inAppWebView.setOnTouchListener(new View.OnTouchListener() {
#Override
public boolean onTouch(View v, MotionEvent event) {
switch (event.getAction()) {
case MotionEvent.ACTION_DOWN:
case MotionEvent.ACTION_UP:
if (!v.hasFocus()) {
v.requestFocus();
}
break;
}
return false;
}
});
Any suggestions?
Though now probably seomewhat outdated, the solution can be found at https://issues.apache.org/jira/browse/CB-11248
Basically, you need to change onPageFinished to
public void onPageFinished(WebView view, String url) {
super.onPageFinished(view, url);
view.clearFocus();
view.requestFocus();
}
After quite some thinking and effort looking through the repo history, we finally nailed it down & fixed it.
While initializing a plugin we did perform some javascript on the WebView. We we're using 'evaluateJavascript' to perform the javascript (this does work on Lollipop, not on KitKat btw), but that somehow had the side-effect of making the caret disappear. After using 'loadUrl' instead, it did work again.
In the javascript we did add a custom attribute (HD_APP) to the window, so nothing that should cause such a side effect. As you can see in the screenshot, the input was no longer identified with ":focus" by css.
Hope this helps..
The thing that caused the issue for me is that I called evaluateJavascript before I had any page loaded.
After I made sure that my page was ready for JS before sending any, the issue disappeared.
I need to get some information from the on screen keyboard such as pressure, KeyDown and KeyUp in Android but don't know how to do that.
The android official site says that:
Note: When handling keyboard events with the KeyEvent class and
related APIs, you should expect that such keyboard events come only
from a hardware keyboard. You should never rely on receiving key
events for any key on a soft input method (an on-screen keyboard).
I also tried the following method without success. It actually works with the hardware keys like back button.
myEditText.setOnKeyListener(new View.OnKeyListener() {
#Override
public boolean onKey(View view, int i, KeyEvent keyEvent) {
return false;
}
});
I was thinking of finding a way of extending the on screen keyboard, but still no success!
Does anyone have ever tried doing this? I'd appreciate your help in advance.
UPDATE:
After trying many solutions I came up with the same solution of using my own keyboard, suggested by krossovochkin, ultimately. It seems that the solution is not too bad if one wants to modify the Android's keyboard as a new one. This way, it appears in the "Settings --> Input Methods" so that the user can switch to the new keyboard, which is good since it is accessible from all other apps. Since it is not yet clear that whether it is possible to get the pressure from the standard virtual keyboard, therefore I thought the question could be left open.
You can try to call getPressure() method from MotionEvent
Link: http://developer.android.com/reference/android/view/MotionEvent.html#getPressure%28int%29
Code snippet:
view.setOnTouchListener(new View.OnTouchListener() {
#Override
public boolean onTouch(View v, MotionEvent event) {
float pressure = event.getPressure();
}
});
UPDATE:
You can create your own keyboard and getPressure from it.
Maybe user will not like using your keyboard instead of his default keyboard.
But I think this is the best solution for your situation.
More information about:
KeyboardView: http://developer.android.com/reference/android/inputmethodservice/KeyboardView.html
Example of creating your own keyboard:
https://github.com/rciovati/Android-KeyboardView-Example
I am seeing some unexpected behavior when using a WebView in Android 4.4 (build target 18). One one page in particular we have some edit text fields, and to get the soft keyboard to pop up appropriately, we had to use a code snippet similar to the ones described here:
https://code.google.com/p/android/issues/detail?id=7189
webview.setOnTouchListener(new View.OnTouchListener() {
#Override
public boolean onTouch(View v, MotionEvent event) {
switch (event.getAction()) {
case MotionEvent.ACTION_DOWN:
case MotionEvent.ACTION_UP:
if (!v.hasFocus()) {
v.requestFocus();
}
break;
}
return false;
}
});
This worked as expected up through version 4.3, but beginning with 4.4 the code above caused an undesired effect of having the content of the webview snap/scroll back to the top of the page on the completion of a touch - after scrolling down the page.
Has anyone else experienced this new behavior - or figured out a workaround? The only thing I have come up with so far would be to subclass a webview that allows the edits (so the code above can be removed from read-only pages that now have the scrolling issue). Of course, if a page both scrolls and has edit fields, this would not work.
Thanks in advance!
I'm currently fighting against the OnLongClickListener on Android Api Lvl 8.
Take this code:
this.webView.setOnLongClickListener(new OnLongClickListener() {
#Override
public boolean onLongClick(View v) {
System.out.println("long click");
return true;
}
});
It works perfectly. I can press anywhere on the WebView and the event triggers every time.
Now take a look at this one:
this.webView.setOnLongClickListener(new OnLongClickListener() {
#Override
public boolean onLongClick(View v) {
final EditText editText = getUrlTextField();
switch (editText.getVisibility()) {
case View.VISIBLE:
editText.setVisibility(View.GONE);
return true;
case View.GONE:
editText.setVisibility(View.VISIBLE);
return true;
default:
return false;
}
}
});
Assuming the URL EditText components is currently visible, it gets gone from the display and should be shown again when another long click event is triggered.
But if you run this, the event just works once (!) when one performs a long click on any position on the WebView. To make things complicated, the long click works again when it is performed on a link on the website...
Can anyone explain if it is a bug in the sdk and/or if there is a mistake in my thinking how the OnLongClickListener is working?!? :/
EDIT:
I've run now several different scenarios on a Nexus One and come to following conclussion: Changing the layout on runtime more or less kills the OnLongClickListener... I haven't found a way to get it work reliably at all...
I would really appreciate if anyone could give me a hint... I'm at my wits end :(
Personnally, I ended up by re-setting the listener after each relayout.
I've run into this issue as well. It seems that if the view layout changes in a way that child view bounds need to be modified (i.e. TextView is wrap_content width and you set its text to something longer/shorter than it was before), views in the hierarchy will have their onStartTemporaryDetach method called (most likely due to a layout pass, although I haven't dug deep enough to find out for sure). If you look at the source for View that onStartTemporaryDetach ultimately unsets the pressed state of the view.
Changing the views in your layout that will be updated periodically to have bounds that will not change regardless of the value you set, will fix the issue. Although, that is still not awesome.