I came up with a temporary workaround for now, but it would need to be added wherever this may happen. (Although, I suppose one could write an override to AbstractComponent, but I personally wouldn't risk the possible problems/conflicts that could occur with the library and/or user extensions.)
This basically stores the scroll values when the element is scrolled, and then restores them when afterComponentLayout() runs.
Would you know if the layout system detaches child elements from the DOM at any point, perhaps to take measurements of a parent element without its children being present? Detaching would definitely cause this issue. Just a thought though, haven't had time to dive into it.
Glad I found this thread. Having the exact same issue and I was going mad trying to come up with a a fix.
I implemented my own virtual scrolling system as the form could contain 500 - 1000 controls. I create a massive scrolling section then recycle the various components by repositioning them as the user scrolls and create new ones for the pool as needed. When I would add those new controls (i.e. when the pool was exhausted of a certain control type), the scrollTop went back to 0. I narrowed it down to the "layout" by using "suspendLayout=true/false" and calling the doLayout() manually to observe the behavior noted more easily.
I'm going to try your work around Gjslick as I can live with some flicker in IE for now with the hope this gets fixed soon!
Update: I tried Gjslick fix and it works except for some reason Chrome loses focus on the scrollbar elevator. As I scroll eventually I need to add a component(s), afterComponentLayout is called and I set scrollTop but the elevator doesn't have focus anymore so I have to re-mouse down on the elevator to continue the drag scrolling. Doesn't happen in Firefox or IE8/9 (only others I tested thus far). Anyway after I set scrollTop to set focus "back" to the scrollbar elevator?
@hooped Unfortunately there is no way (that I know of, anyway) to re-focus the user's mouse on the scrollbar elevator. My workaround is basically a hack unfortunately, and this needs to be fixed within the layout system so that we never lose the scrollbar position in the first place.
@mitchellsimoens Any work being done on this? As soon as a component's layout is executed, we lose the scroll position on both that component, and its parent container's. Makes for a pretty awful experience..
I'm having an issue with a container that is autoScroll:true in a tabpanel where i'm rendering search results. When i scroll down and then change the tab in that tabpanel the scroll positon gets reset when i return to the first tab.
While it sounds the same. This only happens with Internet Explorer. Firefox and Chrome both leave the scroll position unchanged.
The only thing I can suggest is look and see if there is a layout call invoked. Pretty much anything that causes a layout and re-calculation of containers will cause the underlying DIVS to be set to scrollTop = 0. It' spossible that you can adjust your code to not cause the layout call in IE (although it's odd the other browsers would be OK).