IssueTracker

I also have this issue with Android 3.1 (also Samsung Galaxy Tab). I have tested this on a couple of HTC devices running 2.2/2.3, and it works fine there. Also works fine on a Samsung Galaxy S mobile running 2.3.

Also having this issue on Android 4.0.2 and 4.0.3 (Galaxy Nexus, Moto Xoom, Asus Transformer Prime).

I'm seeing this on an ASUS Transformer TF101G with Android 3.2.1 on both the stock browser and Maxthon Mobile browser 1.5 Build 2784.

My test page works correctly on my Linux desktop in Firefox 10.0 and Chromium 15.0.874.106 build. An iPad 2 with iOS 5.0.1 also scrolls correctly. Also the HTC Incredible S with Android 2.3.5 seems to work as expected.

As additional information I would like to mention that appending to a div (that has been scrolled down) visually resets the scrollTop, as the scrollbar and it's content are rendered as if the user did not scroll.

Same issue with Android 4.0.3 running on a Samsung GT-I9100M.

same issue with:

Android 3.2 on Samsung GT-P7510 (tab 10.1)
Andoroid 4.0.3 on Samsung GT-P5113 (tab 2 10.1)

Same issue here.

Android 4.0.3 default browser. This has being reported on aug 2011 and it's a shame this hasn't being fixed yet.

Same issue with Android 4.0.4 Galaxy Nexus GSM

After a year,
Status: New

wow... Just wow...

Android 4.0.3 (ACER Iconia TAB A100) not resolved yet!

I really don't think this is a hard issue to solve, why is there no response to this issue? not even a 'we have seen this post and from now on ignore it'.

Worked around bug using webkittransform: translate.

But it does seem like they don't care.

Michael

brevity due to being tapped onto a phone

Michael, when you get to a full size computer could you post or link to more details of your workaround? I'd like to see if it could also be used to work around issue 36940866.

Note that I've mostly only tested this on webkit, I may have some of the individual transform names wrong.

<code>
    setScrollTop: function(inTop) {
        var top = Math.max(0,inTop);
        if (wm.isMobile) { // should always be true for touch events
            top = Math.min(top, this.listNode.clientHeight - this.listNodeWrapper.clientHeight);
            if (dojo.isWebKit) {
                this.listNode.style.WebkitTransform = "translate(0,-" + top + "px)";
            } else if (dojo.isMoz) {
                this.listNode.style.MozTransform = "translate(0,-" + top + "px)";
            } else if (dojo.isOpera) {
                this.listNode.style.OTransform = "translate(0,-" + top + "px)";
            } else if (dojo.isIE) {
                this.listNode.style.MsTransform = "translate(0,-" + top + "px)";
            }
            this.listNode.style.transform = "translate(0,-" + top + "px)";
            this._scrollTop = top;
            this._onScroll();
        } else {
            this.listNode.scrollTop = top + "px";
        }
    },
</code>

Also if you scroll the container manually, it didn't appear to me to set the correct value for the .scrollTop property.

This is a killer, it's basically taken our webapp and made it unusable for ICS devices now.  There's no solution but to suggest users upgrade to a JB device, or downgrade somehow.  PLEASE RAISE THIS PRIORITY!!!!

FWIW, the webkit-transform:translate workaround did not achieve desired results in our application.

Has any solution been found for this problem?

On ICS on an unlocked Samsung GS2 this now appears to be working in the stock browser, Firefox and Chrome but still failing in Dolphin. In the stock browser it may be flaky, there appears to be an appreciable lag in returning scrollTop values. On JellyBean it seems to be working in all browsers (tested on a Nexus 7 tablet). No browsers I've tested in Gingerbread appear to be affected.  

Does anyone have any current information on whether it is now OK in Honeycomb browsers? I have no HC devices for testing currently.

In reply the above comment, it is still a problem in Honeycomb and ICS.  Jellybean uses chrome and that works.  It somewhat works in gingerbred but scrolling DIVs are broken in 2.3x, you can not scroll in the div.  You can try this test page out in the AVD emulator for any version of android.
http://jsfiddle.net/c5aur/7/
http://jsfiddle.net/c5aur/7/embedded/result/

I really wish someone on the android team would take notice to this issue.

You can make scrolling DIVs work in 2.3 but you need to roll your own, although it's relatively easy. My tests now show that scrollTop is not buggy in 2.x so you can make scrolling regions work there. ALL 3.x browsers appear to be broken here. Chrome works in 4.0, but only for users who install it. Dolphin and the stock browser are broken in ICS and Firefox and Opera are also flaky. Jelly Bean is OK, both Opera and all other browsers I've tested there work. I've put up an interactive test page here:

http://www.it-authoring.com/info/dtest.html

It's still quite rough with a few glitches but you can demonstrate the failures and successes quite effectively and it provides quite a lot of additional information.

PS: The demo page in my comment above also lets you activate the scrolling function on 2.3 devices to see if it works. ;-)

This is also an issue for me, using ICS 4.0.3 webview.  

In my case, my workaround is to use CSS (adjusting top and height) to shift the element the desired amount.  For my use case, my workaround fits very well.

Does anyone have a workaround to avoid the stupid scrollTop reset when new content is added?

I can confirm that for 4.0.x (ICS in general) scrollTop is not working as intended.
We're actually using this external JS library as a workaround http://cubiq.org/iscroll-4 and it seems to do the job :)

Let me know if you find a good fix for this really annoying bug.

Thanks, Emanuele.

As far as I can tell, this problem occurs only when overflow is set to 'scroll' but not when set to 'hidden'. In itself that isn't much help because hidden content isn't user-scrollable, although it can be scrolled by script.
To get around this issue, I wrote the following crutchware that when run on a touchscreen device, just sets specified divs to overflow:hidden. Basic touch handlers allow the content to be swiped, although if you want overscroll they should be deleted in favour of a routine designed to provide it.
It works on the broken browsers, and while it seems not to inhibit those that don't need it (tested on FireFox and Opera Androids), further client detection could be added.

<script type='text/javascript'> /* Must be positioned BELOW all involved divs */

 function noBarsOnTouchScreen()
 {
   var elem, tx, ty;
 
   if( 'ontouchstart' in document.documentElement )
     for( var i = 0, arg; ( arg = arguments[ i ] ); i++ )
       if( ( elem = document.getElementById( arg ) ) )
       {
         elem.style.overflow = 'hidden';
         elem.ontouchstart = ts;
         elem.ontouchmove = tm;
       }
             
   function ts( e )  
   {
     var tch;
     
     if(  e.touches.length == 1 )
     {
       e.stopPropagation();
       tch = e.touches[ 0 ];
       tx = tch.pageX;
       ty = tch.pageY;
     }
   }
   
   function tm( e )  
   {
     var tch;
     
     if(  e.touches.length == 1 )
     {
       e.preventDefault(); e.stopPropagation();
       tch = e.touches[ 0 ];
       this.scrollTop +=  ty - tch.pageY;
       this.scrollLeft += tx - tch.pageX ;
       ty = tch.pageY;
       tx = tch.pageX;
     }
   }      
 }
 
 noBarsOnTouchScreen( 'myDiv_1', 'myDiv_2', 'myDiv_3' ); // <- Specify IDs of all required divs here.

</script>

I found this workaround to work for me:  because the issue only seems to appear when the overflow property is set to scroll, you can first set it to 'hidden', set the scrollTop property, then reset it back to 'scroll' (or auto).  The scrollTop property seems to be honored when the element is re-rendered with scrollbars.  It's not clear if this has any unexpected side-effects, but "it works on my machine!" :)

Hope that helps someone.

Thanks  al...@allanandshelley.ca,

I test your idea in My ASUS TRANSFORMERS PRIME and it's working fine...

You save my day

I've read about the overflow workaround on several sites. It doesn't seem to work when you are coding against the body tag of an iframe in the page. I haven't tried to load my content into a div within the iframe body tag yet.

Google Android Team ... the freak'in least you could do is just ANSWER the issue. If it's going to be a DNF, then fine ... let us know that. At least with that knowledge, I can simply prevent this interface from loading into this browser and tell the user, 'Sorry ... you should have purchased a Windows or iPhone device!'

[Comment deleted]

My workaround to send the content back to the top:

var el = document.getElementById('content');
el.style.display='none';
setTimeout(function() {
    el.style.display='';
}, 100);

Don´t know if this is the same issue or another one but when using an element with overflow: scroll; or overflow: auto; the click handlers inside the scrollable area gets the wrong coordinates. If there are, say, a list of five items then the rest is below and outside the visible area then scrolling down so that list-items 8 to 12 are visible. And then clicking one of those will fire the event-handler from the corresponding one from the first five visible list-items. Maybe set this to a higher priority? Tested with the Stock browser on a Samsung tablet with Android version 4.0.4.

I am also facing the same issue. I think, the problem is related to scrollTop.

The specific issue with click co-ordinates on scrolled elements is: https://code.google.com/p/android/issues/detail?id=25766

I think the two problems may have the same underlying cause,

Thank you so much! You are a genius!

This is fixed in the latest Android 4.4 KitKat, as it now uses Chrome for all WebViews.