I've got the feeling that javascript itself is pretty fast in an andorid webview, but there is a long delay between touching an element and the onclick event beeing fired.
I could imagine that this is a feature if you navigate between pages - you first see the highlight on the element, and then you see the effect (navigation). But for applications, this is too slow.
Is there a way to change this behavior?
Or is there maybe another event I should go for, like an onHover or onTouch? Something which fires way before the onClick?
This is a known 'issue' related to 300ms due to user tapping/zooming at display:
http://updates.html5rocks.com/2013/12/300ms-tap-delay-gone-away
In the near future, this seems to be solved, in static sized layouts, adding information at header. But the actual webkit webview version does not have/consider this option.
In my case, the solution was use Tappy lib:
https://github.com/filamentgroup/tappy
Just import it, and bind to each element that has an click event, and you will see the difference.
Just one more point: I adjusted the timer to 100000ms (default:1000ms) to avoid event repetition in some specific cases.
I guess I've found the answer...
If you take a look at jQuery mobile, you'll find a tap event. This works instantly - exactly as I need it.
Looking deeper into the source, I've found that the tap event uses a mousedown ....
Related
I have a floating app which works perfectly.
I am using OnTouchListener to catch events since I need to use the GestureDetector for swipes etc.
My only problem is that sometimes I wish to ignore certain events on the view.
In this case the view is invisible but not "gone" because I need it to accept certain gestures but not others.
I can't seem to be able to do that.
Returning false from "onTouch" simply doesn't work.
I checked that by experiment by disabling the GestureDetector and simply always returning false just to see what would happen. Result was nothing going through.
Is it even possible to pass a click through to a covered app?
Due to security reasons it's not possible to record and pass a click below (essentially allows building a keylogger).
Best you can do is have your floating window small enough to start the touch but not cover too much of the screen below.
I have a ScrollView with 20 WebViews inside (yes, I know it's heavy but right now it's the best solution I've found). The WebViews are used to display forum posts.
I'm getting a very weird behavior on my Nexus 4 (it doesn't happen on some other devices I've tested) which is driving me crazy.
I have the first post visible and just a little bit of the second one visible. Now I want to scroll and instead of starting scrolling by putting the finger in the first post I put the finger on the portion of the second post that is visible. The WebView of that second post immediately jumps to the bottom which is a very annoying behavior while scrolling.
If you feel appropriate I can record a video of this behavior and upload to YouTube or you can search for AndroidPIT in the Play Store and check the behavior yourself in the Forum section. I won't post the link to the Play Store to avoid being called a spammer.
Thanks in advance.
From comment: "Have you tried setting your webview to non focusable and non clickable as it appears as it's trying to display the entire content of the item you are pressing on as you scroll"
Apparently View#setFocusable (view.setFocusable(false)) worked.
Make sure that the scrolling is handled by the scrollview in stead of the webview. I believe setting the Webview.canscrollvertically to false might fix the problem, let me know if it helped.
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
I'm developing a mobile app in jQueryMobile and PhoneGap. Often, due to the nature of jQM or because it's about loading data, a page will need some last-minute adjustments before it is shown. For example, form fields need to be filled in with dynamically retrieved data, or the contents of list items need to be given a slightly different style in order to fit better.
I am currently doing all these adjustments using the pageBeforeShow event handler. But I wonder if I shouldn't have been using the pageBeforeChange event handler. The jQM docs do not really make it clear how these two events relate to each other, i.e. which is fired first.
What I know
I do know the following
pageBeforeShow and pageShow are triggered after all of jQM's markup (e.g. making list items look pretty) has been applied.
pageBeforeShow and pageShow are bound to a specific page, whereas pageChange is called whenever a change of page occurs (so if you want to make specifi changes to one page before the user gets there, you need to test the event.toPage property)
Why I'm asking
And this is the background why I want to know if page(Before)Change is a better candidate.
jQuery Mobile page transitions are awkward on many devices. The big issue on Android devices is that page changes are jumpy: regardless of the transition type (fade, pop, etc), the page being left by the user will pop back into view briefly after the new page has more or less finished in the browser.
In my experience, this occurs mostly when other animations are running or are started while the page transition takes place. Basically, the Android browser doesn't seem to want to apply transitions to elements that are not actually in view, and it will flip back and forth between jQM pages as a result.
I've already developed a workaround where I delay any markup and form adjustments for a page by about 1000ms, which prevents the flashing but does mean that the user may be seeing these adjustments happen on screen after the page has come into view.
This analysis makes me think that pageBeforeChange might be a better candidate for attaching any markup and form adjustments. But it will be a big rewrite of the code, and I don't know what unforeseen stuff I will be getting into. Anyone have any experience with these events?
I'm not sure pagebeforechange would be the best place to do this. I don't see pagebeforechange as a page-level event, but more of a site-level event. I use it mainly if I want to take over navigation or to build dynamic pages.
I use pageinit when I want to attach event handlers to a page. I use pagebeforeshow when I want to change the contents or look of a page before it is shown.
Hope this helps.
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.