If you're ever using CollapsablePanelExtender, and have a display bug where elements at the bottom of the content area appear for a split second as the control renders and then immediately disappear from view, chances are those elements are floating and you're viewing in Firefox.  (Or else something else crazy and totally unrelated is happening and good luck to you my friend!)

Basically, for CollapsablePanelExtender to work, it has to be able to tell how tall the content area is, and then animate an expansion and collapse between that full height and no height.  This works fine in IE7 with floated elements at the bottom of the content, because Trident doesn't treat css float the way the standard says it should; that is, floated elements still have box model implications, most notably that they often push elements clear of them when they shouldn't.  Firefox, on the other hand, complies with the letter of the CSS standard and floated elements are essentially excluded from the box model in those particular ways as it renders.  This will sometimes cause the containing div to be shorter from the top of the page than the designer expects.  In this case, however, it wasn't, except with CollapsablePanelExtender...  Which apparently won't detect the implications of the floating elements at the bottom of the content when it determines how tall the content pane is, and then will set the height of the content pane to what it thinks it should be...

Boom, your floated elements disappear. 

Which is really annoying when they're buttons, and it means you can't perform any of the actions the dialog should allow you to do because you can't see the buttons to click on them!

This problem went away when I added an empty  <div style="clear:both;"></div> after the content area in the hosting element, which you probably know is a pretty standard fix for this "containing div needs to extend past elements in Firefox but looks OK in IE" problem.  The surprise was just that it was specifically CollapsablePanelExtender that was causing it, as those AJAX Control Toolkit controls are usually pretty good about cross-browser compliancy...  And confusing to diagnose, as the buttons would appear for a split second and then get swallowed up again as the Extender finished loading its scripts.

In fact, I haven't tested it, but I wouldn't be surprised if this behavior is fixed in .NET 3.5 SP1, given that the teams testing ASP.NET AJAX in IE8 with standards compliance mode turned on have probably noticed this bug...