This question already has answers here:
Android 4.3 and PhoneGap, cant tap link
(2 answers)
Closed 8 years ago.
I'm wrapping an Android app using a WebView and it requires rendering an HTML5 canvas. It works perfectly on all my devices, except for one. My Galaxy S4 (4.2.2) is flashing the canvas, then it quickly turns grey. Here is the logcat message it's producing:
D/GestureDetector(20071): [Surface Touch Event] mSweepDown False,
mLRSDCnt : -1 mTouchCnt : 7 mFalseSizeCnt:0
V/WebViewInputDispatcher(20071): blockWebkitDraw
V/WebViewInputDispatcher(20071): blockWebkitDraw lockedfalse
D/webview(20071): blockWebkitViewMessage= false
I click on a button, then the canvas is supposed to render. That is why the first log item is for a surface touch event. It works on my S4 when I ping my app using the webkit browser directly, but when wrapping it myself or using Cordova is gives me that error. I've added two screenshots to further display the issue. The first is rendered correctly and the second is the problem.
Android 2.3.6:
Android: 4.2.2:
So back to my question. What's going on with this message? Does anybody have any suggestions on how to have it properly render the canvas?
I was able to fix the problem by setting my minimum sdk version in the android manifest file to 14:
<uses-sdk android:minSdkVersion="14" />
At version 14, the messages still appear in the log, but the touch events are processed. When I set the minSdkVersion back, the touch events are not processed. Turning off hardware acceleration in the manifest, as well as by various CSS webkit styles, did not help. Only the minSdkVersion setting fixed it for me.
Somehow, on the Galaxy Tab, the SDK support for older versions causes problems with the javascript touch event processing, and blockWebkitDraw stays true while a touch move is happening. This prevents my canvas code from receiving the touchmove events and executing the draw. When I set the SDK version to 14, blockWebkitDraw gets set to true when a touch event fires, but it is unset after the touch is processed, and the canvas code to draw gets called.
I did some cursory browsing of the WebView and WebViewInputDispatcher classes, but didn't come up with anything. Maybe you could take a look there.
http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.2.2_r1/android/webkit/WebView.java
http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.2.2_r1/android/webkit/WebViewInputDispatcher.java
My thought was that perhaps you could pinpoint where the blocking occurs and either extend those classes or create your own copy and modify them.
I was banging my head with a very similar issue while testing on a Galaxy Tab 2. In my case, I had a simple hyperlink, not a button, but the issue is the same. Here's what I discovered:
The error message in my console with tag WebViewInputDispatcher and value blockWebkitDraw lockedfalse appears to occur every single time I touch the screen, regardless of whether I click on a button or link. Therefore, this error message relates to onTouch events, not your button click as you might have expected.
When originally testing by clicking on one of my links, I originally thought the Galaxy Tab was blocking my link. It turns out, the Galaxy Tab 2 is just very insensitive to click behavior so when I thought I was clicking on the link, I was actually missing. By clicking slightly higher than I thought was necessary, I was able to activate my link.
To validate my suspicion, I greatly increased the font size of my link. With the much bigger link, I am able to click the link successfully on the first try, and my app now performs as expected. I strongly suspect that if you just make your button a lot bigger, you'll be able to click it successfully.
I had a similar problem on Galaxy S3. I found the solution in this answer: https://stackoverflow.com/a/20433029/3531606.
The problem was solved by adding the following css to all problematic DOM elements:
-webkit-transform: translate3d(0,0,0);
transform: translate3d(0, 0, 0);
Applying translate3d to element can turn on hardware acceleration on some devices (see this answer: https://stackoverflow.com/a/18529444/3531606), so it may help with the rendering too.
Related
in my current app i have a strange effect. Throughout the whole app the touch feedback is some kind of broken. It seems that at a touch an image of a shadow is rendered onto the elements. This only happends on API 20 and lower.
Any idea what can cause this effect and how to fix this?
Edit
I think i finally solved it. I looks like it somehow depends on Java 8. Since i switched back to Java 7 the problems are gone.
I have a laptop running windows 8.1 with a touch enabled screen.
I am using arc to run apk on the laptop.
The touch works fine on ARC welder but after launching apk, the touch event does not work on app's screen. Just the mouse event works.
I have tried multiple apks and everyone behaves same.
Do we have to enable something to make the touch events work?
This is a bug that has been reported here:
https://code.google.com/p/chromium/issues/detail?id=480745
So a way of getting around this at least for map applications is to specifically code the APK to handle the event and you must use the Arc-Metadata tag of
"enableSynthesizeTouchEventsOnWheel": false, this stops the runtime from trying to interpret your scroll wheel as a touch instead of the SOURCE_CLASS it is.
So for the input device SOURCE_CLASS_POINTER, you have to define ACTION_SCROLL so that a mouse scroll wheel will allow you to do actions. There is plenty of examples of how to do this all over StackOverflow though, just disable that meta-tag and most of the code you normally use for making things work in Android will work here.
Note: Haven't tried "enableSynthesizeTouchEventsOnClick": false, and testing with SOURCE_ that equals a external touchscreen but i believe it would work .
While developing an app wich uses phonegap, angular touch and jquery we stumble in this bug on some android devices.
When touch and move over an non scrollable object the screen goes blank.
When scrooling the body the screen comes back to life.
All the elements stays in dom and still firing events and so.
When using developer tools we still can see the elements.
http://youtu.be/NdTerKi08WE
Has any one saw this bug before?
EDIT
Im using phongegap build so i dont have access to java files.
This problem is only on Android 5 phones.
EDIT 2
Same problem on device chrome browser so its probably not an phone gap problem.
The problem was an issue regard to rtl in the new chromium.
The workaround is to add the "rtl" to css on document ready.
This question already has answers here:
Android 4.3 and PhoneGap, cant tap link
(2 answers)
Closed 8 years ago.
I'm developing app on phonegap, when i execute my app on Samsung Galaxy S4 and in sony ericsson device i'm getting the following error "blockWebkitDraw lockedfalse".
many click events are not working properly and on the above mentioned devices my app seems not working, no events are getting triggered and i get the error "blockWebkitDraw lockedfalse"
Please any one suggest how to fix the problem.
Thanks in advance.
I was banging my head with a very similar issue while testing on a Galaxy Tab 2. Here's what I discovered:
The error message in my console with tag WebViewInputDispatcher and value blockWebkitDraw lockedfalse appears to occur every single time I touch the screen, regardless of whether I click on a button or link. Therefore, this error message relates to onTouch events, not your click events as you might have expected.
When originally testing by clicking on one of my links, I originally thought the Galaxy Tab was blocking my link. It turns out, the Galaxy Tab 2 is just very insensitive to click behavior so when I thought I was clicking on the link, I was actually missing. By clicking slightly higher than I thought was necessary, I was able to activate my link.
To validate my suspicion, I greatly increased the font size of my link. With the much bigger link, I am able to click the link successfully on the first try, and my app now performs as expected. I strongly suspect that if you just make your clickable elements a lot bigger, you'll be able to click them successfully.
Hello I had the same problem and it was driving me nuts. I solved it by adding a listener to a touch event, in my case it was touchmove, the listener executed e.preventDefault(); e.stopPropagation();
this solved the issue I was having but did not prevent the notices in logcat.
I had the same problem with samsung tab 2. I read it somewhere samsung's hardware acceleration broken webkit. The problem went aways after I turned off hardware acceleration in android manifest.
I'm building an html5 wrapped iOS / Android app with Trigger.io.
I have a problem on Android with a grey background appearing on the screen in some occasions after the virtual keyboard has closed, or after the phone has changed orientation.
Example screenshots are shown below.
The grey background is after the end of my app's page. Sometimes it is visible for a split second, other times it stays visible until you make an action such as scroll the page, bring the keyboard back, change orientation.
It's pretty jarring to look at.
I'd ideally like to stop the issue occurring, but as a temporary fix I'd be happy with being able to set the grey to my own background colour to make it less noticeable.
This looks like the HTML's not being re-drawn when the keyboard disappears... does it clear up if you do something to trigger a render?
Are you using a framework to handle the UI here? Something that might be trying to do something clever based on the visible viewport?
From what I can tell, the root of the issue is in the webview not re-drawing correctly, or something in your JavaScript failing to respond to the viewport changing size.
You could try running the app on the "web" target (instead of Android) then opening it in your phone's browser: if you can get far enough into the app to create the same effect it would help isolate the problem to the webview rendering or your JS.
I had a very similar issue in my project, in my case on Android 2.3.5 but not on Android 4.*. The cause in my case was not setting a window soft input mode for the associated activity in the manifest:
android:windowSoftInputMode="adjustPan"
Instead, the window was resizing when the keyboard appeared but apparently not resizing once more when the keyboard disappeared.
More details can be found here.
I almost went crazy with the same issue. I finally found out that this largely depends on the device you are using. I had a similar problem : Fixed elements (HTML) break after android keyboard dissapears?
And I am also using trigger.io. This doesn't happen with some devices. Could be the particular OS in android or could just be the way the specific device handles the memory latency.
I have looked for this but I go with #jamesbrady in that the HTML doesn't redraw. The problem in trigger is that you cannot edit the
android:windowSoftInputMode="adjustPan"
because the activity tag in the AndroidManifest.xml updates on each run. You would need to build a private module for that.