17

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:

enter image description here

Android: 4.2.2:

enter image description here

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?

Joshua
  • 1,260
  • 3
  • 17
  • 33
  • Have you tried a few different web pages to see what it is about the web page that is causing this or is it every web page? – hack_on Oct 02 '13 at 10:01
  • It means webkit blocked drawing thread unitl dispatch event finished. –  Oct 03 '13 at 18:11
  • It only happens with hardware acceleration enabled on Android 4.2+ devices. Is there a way to have it not block it without disable acceleration? Blocking things causes problems with animations and real-time touch events, but with no acceleration things tend to run less smoothly. – Joshua Oct 04 '13 at 04:08
  • @Josh: any solution or work around? – Reaz Patwary Feb 28 '14 at 19:30
  • Still haven't figured out exactly what blockWebkitDraw is doing or means, but our problems seemed to steam from webviews poorly (or rather not) handling html overflow. In particular any overflow-x of any kind caused things to go haywire. It's handled much nicer in Android 4.4. – Joshua Feb 28 '14 at 21:28
  • @Josh Can you share more details about the code, the html, js and css? A jsfiddle probably – aravind Mar 17 '14 at 14:42
  • On my Galaxy Galaxy Tab Android 4.2.2 only disabling hardware acceleration 'solved' the problem. – Christian Schulzendorff Jan 09 '15 at 16:57
  • The only sure fire way for web applications to work on Android is using something like https://crosswalk-project.org/ – Joshua Jan 10 '15 at 18:21

4 Answers4

2

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.

NoelHunter
  • 996
  • 9
  • 17
1

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.

JstnPwll
  • 8,585
  • 2
  • 33
  • 56
1

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.

Steven
  • 2,054
  • 1
  • 18
  • 13
1

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.

Community
  • 1
  • 1
Lukas Vrabel
  • 807
  • 9
  • 17
  • allow javascript to the webview work for me, the css not work WebSettings webSettings = myWebView.getSettings(); webSettings.setJavaScriptEnabled(true); – angel Dec 11 '15 at 23:41