Code:
First some background. It is an established fact that the Droid browser has idiosyncrasies that can interfere with programmatic control. I first noticed this with the behavior of the back button. After much testing and help-seeking, I concluded that there was a hardware glitch in the Droid and started a forum thread about my findings titled, “[COLOR=#323232][FONT=Verdana]Droid backbutton vs. Iphone backbutton.[/FONT][/COLOR]” There was skepticism about my claims in the thread at first, but a month after it started, someone confirmed my findings and provided a technical explanation for the undesired behavior I’d been observing. (pseudomammal on 10/14, if you’re interested).
Well now I’ve come up with a second Droid-browser-only glitch where it seems to defy Java control. I have a running example where the problem can be reproduced: just go to [URL="http://www.tofilmfest.ca/tiffwidget"][U][COLOR=#810081]www.tofilmfest.ca/tiffwidget[/COLOR][/U][/URL], choose “schedule and lists,” then choose “next,” and you’ll be at a multi-paged gridview with page command buttons at the top and bottom. If you go to the bottom and press the next page button, it will turn the page and then go to the top of the form – IF you’re using a desktop browser or an iPhone browser. With a Droid, it turns the page and goes to the top momentarily … after which, it goes right back down to the bottom.
Here is the Java code that makes it go to the top:
[CODE]Sys.WebForms.PageRequestManager.getInstance().add_pageLoaded(PageLoadedHandler);
[COLOR=blue]function[/COLOR] PageLoadedHandler(sender, args) {
[COLOR=blue]var[/COLOR] dataItems = args.get_dataItems();
[COLOR=blue]if[/COLOR] (dataItems[[COLOR=maroon]'GridViewCommand'[/COLOR]] == [COLOR=maroon]'Page'[/COLOR]) {
window.scrollTo(0, 0);
pageTracker._trackPageview([COLOR=maroon]'Pageturn'[/COLOR]);
}
}