@Animal I was super hopeful, but unfortunately adding hideMode: 'offsets' to each component in my example fiddle doesn't seem to have any effect. If the first panel is scrolled down, expanding/collapsing any of the other panels resets its scroll position. http://jsfiddle.net/hJcQ3/6
@Mankz Unfortunately, it seems to be an issue in every browser, with the biggest issue being in IE (as per usual..).
The exact reason that the scroll position is lost when a layout is executed is because:
1) The explicit height of the component ('100px') is removed, and then
2) The explicit height of '100px' is put back.
When the explicit height of 100px is removed, the component goes to its auto size. The auto size is its full content height, so it no longer has any scroll height. Therefore, its scrollTop is reset back to 0. Then, when the explicit height is re-added again, we still have the scrollTop at 0 - not the original scrollTop.
The explicit height removal in this example happens in the Auto component layout's beginLayoutCycle() method. http://docs.sencha.com/ext-js/4-1/so...ginLayoutCycle. The statement which is executed is: owner.el.setHeight(null); Try out my example and set your debugger to break on that statement (it's line 43297 of ext-all-debug.js), then step over. You'll see what I mean.
Hope this helps to assist in figuring out a workaround!
So your minHeight setting should prevent resetting all the way back (which is needed when laying out a shrinkwrapped item - it should relinquish any previously set height), it should fall back to its minHeight.
Hey guys, wow, sorry for the superlate reply. I didn't notice that you guys posted!
Animal, that would be an awesome fix, and it actually fixes the accordion issue too, except that it doesn't allow the content to re-shrink afterwards... Check out this example: http://jsfiddle.net/gjslick/MNyCa/1/
First click "Add Content," and then "Remove Content." Without the override, it shrinks correctly.
I think you're on the right track though, not allowing the component to expand past its maximums when re-laying out. This maintains the scroll position. Perhaps we need something to shrink it back during the "calculate", or in one of the "after" phases?
Using that, I was able to dynamically add items to the container as the user was scrolling without it resetting the scroll position a back to the top.
Before I was just doing a single add like I am now, but if layout was running, it caused the problem. I'm assuming if layout is active when adding items that's when it goes through turning off scrolling as mentioned above, but not sure.
Are there any chances for fixing this bug in the next patch/minor release?
It seriously breaks a crucial functionality in our app. None of the workarounds proposed in this thread work in acceptable way...