I've been using iScroll for a while now, but it wasn't until the other
day when I noticed the issues on the HTC Desire. I've managed to have
a work around (thanks to DDMS!), and details are below:
Just as a quick recap, what was happening was that at some points, the
webview would just freeze. It was usually after scrolling (not
natively, but with iScroll), and sometimes after initialising a
touchmove event on an element not within the iScroll wrapper. In DDMS,
I noticed that there were two messages popping up every time this
happened. The first happened on all touchend events, the second when
11-01 11:35:56.007: WARN/webview(1503): Miss a drag as we are waiting
for WebCore's response for touch down.
11-01 11:31:28.945: DEBUG/webkit-timers(1503):
[JWebCoreJavaBridge::pause] >> do pause
The first one was a red-herring, and wasn't causing any noticable
problems. The second, however, was the cause of the crash.
Looking at the JWebCoreJavaBridge.java file here, it seems that WebKit
has a collection of timers that (for want of a better description)
time stuff. They seem to listen out for webkit events (like touch
events, transition events, etc), and if these timers are paused, no
webkit events are detected at all; so it's not so much of a crash as
WebKit deciding to stop listening.
I noticed that these timers were resumed after a touchend event
(paused on touchmove), and so getting them to resume again was pretty
important. In my code, I had:
document.addEventListener('touchmove', stopMove, false);
Where 'stopMove' was a function that just called e.preventDefault();.
Removing this fixed the issue with the timers not resuming when doing
a touchmove event on elements not within the iScroll wrapper.
Aaaanyway, onto the iScroll issue (!); I'm using the latest version of
iScroll for the line number references. On lines 64 - 66, the start/
move/end listeners are all added at the same time. I removed the move/
end listeners and put them in the touchstart function (just like how
NoClickDelay does it). I removed ALL the touch listeners on touchend
and added them again at the end of the resetPosition() function. I did
this because when iScroll was 'doing the momentum' transition, the HTC
Desire hates having touchevents registering, and this was what was
causing the JWebCoreJavaBridge to 'do pause'. In some ways, it's a
compromise because now I can't stop a momentum scroll once it's
happening, but it all depends on how 'native' iScroll on Android has
to be. Removing momentum, of course, will stop all of this happening,
and is a much quicker fix. Still, it was an interesting adventure!
Hope this helps someone, and apologies for the length :)
> > >> Android 2.2 (HTCDesire) mobile and the scroll is not that fluid on is
> > >> Works great on iPhone, but on the *HTCDesire* it's not that smooth. It