WebView fails to render until touched Android 4.2.2 [duplicate]

Question

I am developing an open-source browser called Lightning Browser, and I have run into some trouble with the most recent update to Android (4.2.2).

WebViews will fail to render completely until the view is touched. It only occurs on the latest Android version. On 4.2.1, the WebView rendered completely fine. I use my Nexus 7 for development and right after I received the 4.2.2 update, the browser stopped rendering. Other users experienced this as well, and it was confirmed multiple times to happen ONLY on 4.2.2. It is happening targeting API level 16 and 17, but I have seen a WebKit browser that targets API level 9 without this problem.

I have attempted to remedy this using the solution to a problem I found here on Stack Overflow (Android WebView renders blank/white, view doesn't update on css changes or HTML changes, animations are choppy). HOWEVER, setting the WebView's RenderPriority to high alone does not solve it... the only way to get it to render without being touched was to place the invalidate() command inside the OnDraw() method of WebView. This causes the WebView to re-draw continuously. This works (sort of), animations are smooth, the page loads very quickly, but it causes the WebView's performance to drop otherwise.

I have also seen this question (very similar to mine), but there is no good answer for it. Android WebView Fails to Completely Render Content Until User Interaction

By performance drop, I mean input. Text input lags, and the WebView itself cannot handle what is going on as well as before. Benchmarking the browser with the invalidate() method call drops Benchmarking performance by around 8%. I know benchmarks aren't everything, but it's telling me that the continuous drawing is straining the system and causing the system to ignore other tasks.

In Conclusion... The WebView in Android 4.2.2 will not render until touched. The only way I know to fix this is to call invalidate() in the onDraw() method of WebView. This is bad for performance and I am looking for a different way to fix this.

The Magic Code (I'm currently using)...

class MyWebView extends WebView {     @Override     onDraw(Canvas canvas)     {         invalidate();          super.OnDraw(canvas);     } } 

remove

invalidate(); 

and it doesn't render until touched.

Does anyone have a suggestions on how make the WebView render (other than what I've done)? By the way, this is my first question I've asked here on Stack, so forgive me if I haven't been clear or if I've done something wrong.

EDIT: I found this question here about a similar issue and it was resolved, the problem is, I don't understand what the answer even means. If anyone could enlighten me it might help.

I get this error in logcat

E/chromium(1243): external/chromium/net/disk_cache/backend_impl.cc:2022: [0705/172030:ERROR:backend_impl.cc(2022)] Corrupt Index file 

Answer 1

So I finally found the issue causing the WebView not to render. I am starting and stopping the animation of a drawable inside the WebViewClient of my WebView. This drawable is simply a refresh button that rotates when the page is loading... simple right?

Well in the non-fullscreen mode of the browser, the rotating drawable and the WebView are both children of the same parent, whereas in the fullscreen mode, the drawable becomes a child of the WebView. Somehow, by starting the animation when the page is loading and stopping it when it's done (in fullscreen), the application decides that the rotating drawable is what needs all the drawing power and the WebView never draws. When in fullscreen mode and the drawable becomes a child of the WebView, the WebView then has a higher rendering priority than the drawable and it draws fine.

The moral of the story is... WebViews like to be the highest priority view to be drawn. If there are other views that get greater priority, they won't draw correctly.

I'm no expert on animations, so I need to rethink how I'm animating the drawable now so as to not interrupt the WebView.

Hopefully that made sense. Thanks for reading.