I ended up solving the issue by not using collapsed: true in the initial config, but rather collapsing the panel after rendering, without animating. It seems to happen fast enough to cause no screen flicker. This is in a window with a form that has 6 collapsible fieldsets.

Condor

17 Jul 2009, 10:32 PM

I don't think this will be solved in the Ext 2.x branch.

However, it was fixed in Ext 3.0 (by deffering layout until the panel is expanded).
Unfortunately animation still uses display:none as Animal pointed out.

mystix

6 Aug 2009, 8:53 AM

[ moved to 3.x Bugs from 2.x Bugs ]
with reference to the following thread:
http://extjs.com/forum/showthread.php?t=76784

Animal

6 Aug 2009, 9:33 AM

It's not fixed in that the slideOut effect still uses display: none

Condor

6 Aug 2009, 9:56 AM

You should not consider my patch as the final solution. The problem needs to be handled much deeper down (IMHO animation effects should have the choice of using display, visibility or offsets).

Stefan B

13 Aug 2009, 11:15 PM

However, it was fixed in Ext 3.0 (by deffering layout until the panel is expanded).

Haven't tried in Ext 3.0 yet, but I don't believe deferring layout fixes all implications. It only helps getting the layout right on initial rendering of a panel. But think of things like updating the value of a progress bar that resides in a collapsed container. Its bar element will be sized relative to its main el size, which is zero because the container panel el has "display: none".

Condor's workaround helps here, but using "hideMode" settings for collapsing is the solid way to go.

There's another, slightly off-topic question here:
Since I think this is quite a dirty hack, I don't want to override Ext.Panel's prototype. Instead I tried to create interceptor methods in the panel's config, like so:

This doesn't work, FireBug says "this[this.collapseEl] is undefined".
What's wrong with that? Did I run into a scoping issue that I don't recognize?

Thanks,
Stefan

Stefan B

23 Oct 2009, 3:36 AM

Nevermind my question regarding interceptors. I just realized that the panel's initial config is applied to the border layout region as well, so that in fact i don't just override the relevant panel methods but also the region, which happens to have its own onCollapse, afterCollapse and onExpand methods.
Worked around this by creating the interceptors in the panel's "beforerender" handler.

Thanks,
Stefan

bbxx

23 Oct 2009, 2:50 PM

I have a container within a collapsed panel that does not render. But after I expand the panel and then resize my browser, it renders properly.

I tried condor's fix but it didn't work. Any ideas? It's just a few containers nested with hbox layout

Jamie Avins

11 Feb 2010, 3:52 PM

Fixed in svn-6047 for 3.2.x branch.

lorezyra

31 Jan 2011, 5:56 PM

Fixed in svn-6047 for 3.2.x branch.

Jamie Avins,
I'm using EXTjs 3.3.1 and have the HTMLeditor inside of a Ext.Window component. This buggy behavior still persists when I collapse the window. I have yet to try setting the config animateCollapse to false as suggested by another tread. I've observed that HtmlEditor.reset() method will restore any text that existed in the initial rendering of the component, but all changes from that point are lost.