IE8 doesn't show content on the "manage field" page

Peek-a-boo bug
http://www.positioniseverything.net/explorer/peekaboo.html

This also happens in IE6.

There is a reason why it is set (or at least, why I set in the original patch) to visibility:hidden, to maintain it's height while hiding. This will introduce, a regression, jumping pageheights while loading new pages, guaranteed.

If it really is the peek-a-boo bug, then it should be solved by giving haslayout, as mentioned in the link in #1. Zoom:1 for instance, but I'd not be comfortable setting that anywhere else but in a conditionally commented css file for IE =< 7.

Visibility:hidden is no longer necessary to maintain height. Besides I can't get it working using zoom:1 (maybe its not peek-a-boo after all)

Also, there is a new issue on overlay height while loading: #676008: Overlay's Loading 'spinner' graphic often not visible because it is displayed outside the viewport

Kiphaas7, if you agree on all this you may set this back to RTBC.

Yes, it still is necessary. I just tried out HEAD ,manually setting your patch with firebug.

With patch:
loading image with old height -> jump to whitepage with 50-100px (-ish) height for like 0.1ms -> new height

without patch:
loading image with old height -> jump to whitepage with old height for like 0.1ms -> new height

Basically what was fixed in #664450: Heavy flicker effect due to white background rebuilding every time when going to new page within overlay.

Untill option 2 of #676008: Overlay's Loading 'spinner' graphic often not visible because it is displayed outside the viewport has landed (or something similar, at least so you don't get #664450: Heavy flicker effect due to white background rebuilding every time when going to new page within overlay again), I would hold off on submitting this, otherwise people will start screaming because #664450 will re-appear.

Meh, that might be a more pressing issue :P. RTBC then.

EDIT: Though it needs to be set back to "needs work" after committing this patch, since it still does introduce a regression.

Got where the "jump to extremely small height" comes from. The wrapper get's resized to 25px for a brief moment when the load event fires. And for some reason the min-height on wrapper is set to 0. Solution: either set a min-height for the wrapper, or make sure the height of the wrapper never get's below a certain number.

Um. Wow, that's bad! Thanks for testing, aspilicious, and for the quick fix, casey!

Committed to HEAD. Thanks!

I've set this back as needs work, but I'm wondering if we should just re-open the old issue that fixed this bug originally so that the folks who worked on that original fix can come up with another solution. Unless they're all here already. ;)

It was fixed in one of the monster overlay patches, and then modified from inline styles to a css class in some other issue. I think it's fine to follow up in this issue :).

Please review #676008: Overlay's Loading 'spinner' graphic often not visible because it is displayed outside the viewport to get issue fixed mentioned by @Kiphaas7 in #5 (also see #574164: Fix transitions between pages inside the overlay).

Issue still not fixed, even after applying #676008: Overlay's Loading 'spinner' graphic often not visible because it is displayed outside the viewport.

1. Applied patch in #1
2. Applied patch in #3 from #676008: Overlay's Loading 'spinner' graphic often not visible because it is displayed outside the viewport
3. Progress now:
   • Loading sign with new height (so patch in #676008: Overlay's Loading 'spinner' graphic often not visible because it is displayed outside the viewport works) Screenshot #1.
   • flashes to 25-30px height on the wrapper for like 0.1ms. Screenshot #2., Screenshot #3.
   • Loads new content and new height.

It's the wrapper getting the wrong height in between "loading...." and actually loading.

Not tested, but I think this should work.

Unfortunately, it does not (tried it).

This however, does. I'm still not able to roll patches properly, because my dev pc is still in pieces, sorry for that.

Around line 46:

  resizeTimeoutID: null,
  lastHeight: 0,
+  minHeight: 0,

Around line 280:

  // Reset lastHeight so the overlay fits user's viewport and the loading 
  // spinner is centered.
  self.lastHeight = 0;
  self.outerResize();
+
+  // Set a minimum height equal to the re-calculated lastHeight
+  // to prevent jumping page heights.
+  self.minHeight = self.lastHeight;
+
  // No need to resize when loading.
  clearTimeout(self.resizeTimeoutID);

Around line 300:

  self.$iframe
    .bind('load.overlay-event', function () {
      self.isLoading = false;
+      self.minHeight = 0;

      // Only continue when overlay is still open and not closing.

Around line 584:

  var height;
  // Only set height when iframe content is loaded.
  if ($.isObject(self.$iframeBody)) {
-    height = self.$iframeBody.outerHeight() + 25;
+    height = (self.minHeight == 0) ? self.$iframeBody.outerHeight() + 25 : self.minHeight;

    // Only resize when height actually is changed.
    if (height != self.lastHeight) {

EDIT: minor code change and comment cleanup.

This should work...

You forgot to set to 'needs review' :). Will try out later today.

Yup, it indeed fixes the issue, plus it is much more elegant than mine. Since it is such a small patch, RTBC?

Great!! Committed to HEAD!