Hey guys - I've encountered a bit of a strange WebView interaction that I can't seem to find reported anywhere either in this group or other help forums. I have a basic WebView loaded within an Android app that contains a call to setTimeout. This code looks something like:
setTimeout(function() {}, 120000); I've found that if the screen dims, goes into sleep mode while this timer is executing, and is turned back on / unlocked after a minute or two, the WebView will fail to render any changes to the page until a period of time has elapsed (up to the delay specified in the timer -- 120 seconds). During this "frozen" state, the JS can still receive DOM events and make calls to a native JS-Java bridge. However, it cannot make any changes to the actual UI that will require re-rendering -- any attempt to do so will appear to call through without exception but no change will be made on the screen. As you reduce the delay for the setTimeout call, the average amount of time that the UI freezes reduces as well. You can reproduce this like so: 1. Create a WebView that loads a page containing: JS that makes a call to setTimeout (give it a 2m delay just to highlight the issue) and some sort of page interaction (like a button) that causes a UI change when activated 2. Set your phone's dim / sleep mode configuration to 15s 3. Wait a few minutes (say 3) after your phone has gone into sleep mode 4. Turn on and unlock the phone 5. Attempt to activate the page interaction in your WebView that will attempt to change some aspect of the UI You should notice that it'll take up to 2m for the UI to render your change. For now, I'm working around this by never passing in anything greater than 1000ms to setTimeout within a WebView -- by doing this, the maximum freeze time a user could experience is only 1s instead of 2m. My test setup: - HTC Desire HD - Android 2.2.1 - Kernel 2.6.32.21-gb291666 - Build 1.84.661.1 CL325797 release-keys - WebKit 3.1 So -- anyone have any thoughts on whether this is some strange Android bug, misconfiguration, or expected behavior? As I said, I can certainly work around it for now but I'd love to understand the underlying cause of this issue. Without understanding the internal Android implementation, one might think that the UI thread is locked waiting for the timer to complete. Thanks! -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en