Scroll position lost when Box layout updates

[Gjslick]

Ext version tested:

• Ext 4.1.1

Browser versions tested against:

• Chrome 22
• IE 8
• FF 15

DOCTYPE tested against:

• html

Description:

• When a Box layout updates, the scroll position of its owner container is lost.

Steps to reproduce the problem:

• Check out this fiddle: http://jsfiddle.net/gjslick/fJxkS/4/ (It's an example with HBox layout)
• Scroll down a little, then expand any accordion panel on the left.

The result that was expected:

• The scroll position of the outer panel should remain in place

The result that occurs instead:

• The scroll position of the outer panel is reset to the top

Test Case:

Ext.onReady( function() {
    
    function createAccordionPanels() {
        var panels = [];
        for( var i = 0; i < 25; i++ ) {
            var panel = Ext.create( 'Ext.panel.Panel', {
                title       : "Panel " + i,
                bodyPadding : 10,
                html        : "Test content " + i
            } );
            panels.push( panel );
        }
        return panels;
    }


    function createContent() {
        var str = "";
        for( var i = 0; i <= 50; i++ ) 
            str += i + "<br>";
        return str;
    }


    
    var containerPanel = Ext.create( 'Ext.panel.Panel', {
        renderTo: Ext.getBody(),
        
        height : 300,
        overflowY: 'auto',
        
        layout: 'hbox',
        items: [
            {
                width  : 200,
                layout : 'accordion',
                items  : createAccordionPanels()
            },
            
            {
                flex  : 1,
                xtype : 'component',
                html  : createContent()
            }
        ]
    } );
} );

See this URL for live test case:

• http://jsfiddle.net/gjslick/fJxkS/4/

Cause of problem:

• ​I traced the cause of the problem to the Box layout's beginLayout() method.

beginLayout: function (ownerContext) {
    var me = this,
        smp = me.owner.stretchMaxPartner,
        style = me.innerCt.dom.style,
        names = me.getNames();


     ...


    // Don't allow sizes burned on to the innerCt to influence measurements.
    style.width = '';
    style.height = '';
},

(In the context of my fiddle example)

1. When the line in red executes, there is no longer any height on the innerCt element (it effectively becomes 0, due to the absolutely positioned child targetEl). So its parent element's scrollTop gets reset to 0, because it no longer has any content to scroll.
2. The layout routine continues, sizes everything up, and eventually re-applies the new height to the innerCt element. This causes the scrollbar to re-appear. But, because the scrollTop was already reset to 0, we're left back at the top of the panel.

Possible Fix:

It seems that simply commenting out that line in red, or removing it in an override fixes the problem. However, I don't know what else this might be breaking in the process, as I'm sure it was originally there for a reason.

I thought perhaps that commenting out the line would prevent the shrink wrapping feature from re-collapsing the height of the element once it had lost some content, but apparently this is not the case. Check out this slightly more complex version of the original fiddle, which generates a random amount of new content when the accordion panels are expanded and the layout is refreshed: http://jsfiddle.net/gjslick/3gDGV/1/ It shows that the auto-shrinking feature still seems to work.

Additional CSS used:

• only default ext-all.css

Operating System:

• Win7

[mitchellsimoens]

Thanks for the report! I have opened a bug in our bug tracker.

[Gjslick]

Thanks Mitchell.

[christophe.geiser]

+ one for having a look at this bug.

When you have complex forms within box and with scrollbar, it makes your form jump on any field updates - quite annoying.

Thanks for the proposed fix, it works in my case.

Quite glad I found this post !
Cheers
C.