View Full Version : Layout randomly failing inside iframes

22 Mar 2011, 10:18 AM
I have developed a set of Ext applications accessed by a menu application. The menu application is basically a border layout,
which contains a tree view in the "east" region and a tab panel in the center. The tree view lists to the user the available applications,
so she can choose one or more to open. Upon selecting one application, a new tab is created, which contains an iframe. The application's
url is passed to that iframe to be loaded (the applications themselves are ExtStand-alone pages, which have a viewport with fit layout and inside the viewport a panel or grid)

The problem I'm facing is that, apparently in a random fashion, components don't get rendered correctly inside the iframes.

They appear in random locations or with the incorrect size. The applications render perfectly when invoked stand-alone from outside the menu.
The following screenshots show some examples of this:

https://picasaweb.google.com/lh/photo/Ai3ft5v337vWvicoQkUKzg?feat=directlink (https://picasaweb.google.com/lh/photo/Ai3ft5v337vWvicoQkUKzg?feat=directlink)

https://picasaweb.google.com/lh/photo/vXAspkHMh-5m3BFdrzg-kg?feat=directlink (https://picasaweb.google.com/lh/photo/vXAspkHMh-5m3BFdrzg-kg?feat=directlink)

I've been having this issue mostly with IE, but I was also able to reproduce it (hardly) with FF.
I was using MIF at the time I detected this problem. As I thought MIF could be causing trouble, I replaced it temporarily with a plane iframe, but I got the same results.

One situation which seems to be related to this behavior has to do with keeping focus on the iframe while it its loading.
The layout seems to fail more oftenwhen I try to open a tab, then quickly switching to another already open tab (while the opening tab is still rendering) and then switching backto the just open tab.

I'm also having another issue that was driving me nuts, which could be caused by the same problem. One of the available applications triggers an Ext.Message Box as soon as it opens. In some random situations, I noticed that the application appeared with a gray shade all over it.
After debugging this particular app, I found out that the shade was caused by the modal message box trying to render, but Ext raised an error after trying to calculate its shadow’s position (or size), so the box was never shown (and for that reason, the gray shade never disappeared).
I'm not an Ext-Library expert, but the calculus seems to be getting some negative coordinates causing it to fail.

I am using:
- Ext v 3.3
- MIF v 2.1.3 (although it does not seem to be causing trouble)

- The most of our tests were performed on ie6 because that's our client's choice :-(, but we were able to reproduce with all versiones of IE and with FF.

This applications have already gone into production. I would be very glad and gratefully appreciate if someone can givemeany clue about how to deal withthese issues.

Thanks in advance,

22 Mar 2011, 4:55 PM
Well, random errors are hardest to find. What can have influence is if you use a doctype or not - once using it and other time not using it fixes some problems.

Also, MIF is a great extension so perhaps Dough could help you (you can send him a PM). I personally have little experiences with iframes (no in IE) besides http://examples.extjs.eu that also uses MIF but not in tabs.

23 Mar 2011, 8:57 AM
Hello Saki,
i've checked the doc-types and they're all XHTML 1.0 Transitional.
I'm editing the post to include another issue we were having with messagebox , as I consider it could be related.

23 Mar 2011, 9:32 AM
In your last screenshot I notice that Firefox shows 1 error in the status bar. What is the error? The answer may help diagnose the issue.

I have seen these kind of layout problems before (though not related to MIF or iframe usage in general). Usually the cause has been a FormPanel with incorrect layout specified but I cannot tell if this is the issue you are experiencing.

If you can post a small test case that illustrates the problem with the smallest amount of code possible and without any external dependencies I will be happy to try and assist your debugging efforts.

23 Mar 2011, 9:52 AM
Hello Mike,
yes, you are right,I hadn't noticed it before. I was able to reproduce the problem in firefox and to locate the line that's raising the error. It's the same code that fails when trying to create a messagebox. The following fragment shows the line in context (ext-all-debug.js). I'm going the see if I can debug it any further and if I can prepare a small case that "works".

var supportTests = function () {
var div = document.createElement('div'),
doc = document,
view, last;
div.innerHTML = '<div style="height:30px;width:50px;"><div style="height:20px;width:20px;"></div></div><div style="float:left;background-color:transparent;">';
last = div.lastChild;
if ((view = doc.defaultView)) {
if (view.getComputedStyle(div.firstChild.firstChild, null).marginRight != '0px') {
supports.correctRightMargin = false;
if (view.getComputedStyle(last, null).backgroundColor != 'transparent') {
supports.correctTransparentColor = false;
supports.cssFloat = !! last.style.cssFloat;
}; /* paste in your code and press Beautify button */
if ('this_is' == /an_example/) {
} else {
var a = b ? (c % d) : e[f];

23 Mar 2011, 9:59 AM
Did you manage to fix that error?

You can set firebug to "stop on all errors" and then inspect the call stack.

23 Mar 2011, 10:27 AM
I was able to put a breakpoint in the red line above and to evaluate what it returns. When the layout does OK, the function getComputedStyle returns "0px". Otherwise, when the error ocurrs, it returns null (and therefore raising the error when the comparison against against 0px is made). Any clues?

23 Mar 2011, 10:32 AM
I mean, you can go up the stack to see who's calling that method. A shot in the dark: issues like this can be caused by javascript accessing elements that do not exist (yet).

23 Mar 2011, 11:45 AM
I tried doing so but FB started to stop in just too many places, it became very difficult to debug. However, by looking at the entire library's code, i see that that function is only called once, after the Ext.Onready event.
O.T: While trying to understand what that function does, I found smth. corious in the line

div.innerHTML = '<div style="height:30px;width:50px;"><div style="height:20px;width:20px;"></div></div><div style="float:left;background-color:transparent;">';

why doesnt the transparent div have a closing tag?

23 Mar 2011, 8:46 PM
I have no idea if it is an overlook or if it has some influence on support tests or if the closing is just not necessary because it is added by the browser when appending it to the document.

You can still post it as a bug, devel team will either fix or explain it.

Re FB stops: Normally, Firebug only stops on errors and the application must be error free (means zero errors means zero stops). Thus, I'm quite surprised by:

but FB started to stop in just too many places
Error-free javascript code doesn't stop even if FB is set to "Stop on all errors".

28 Mar 2011, 8:33 AM
Hello Saki,
I have finally writen a minimal and stand-alone example in which the error can be reproduced.
I have made available different instances of the same example for several Ext versions. They can be
accessed from here:




There's also an screen cap showing the error appearing:


Also, the example's code can be downloaded from here:


What I do here is to open a tab with an iframe, which actually just loads the Ext library. Then,
after opening the tab, there's a javascript that switchs back automatically to another tab (so the focus is taken out from the
first tab and thus from the iframe as well).

It's important to point out that I coud not reproduce the error with Ext versions prior to 3.3.0. For example,
with 3.2.1 the error wont ocurr, but it will in 3.3.1. The example is referencing the library and resources directly from http://extjs.cachefly.net
Please try the examples with FF as the other browsers don't seem to report the error (altough they do produce problems with the layout in
my application)

Please let me know if you need more info. Thanks in advance.

28 Mar 2011, 9:54 AM
Yes, I can reproduce it with FF [email protected] I'm moving this thread to Bugs for the devel team to explain/fix.

29 Mar 2011, 11:00 AM
Thanks Saki,
I'd like to keep on tracking this issue in order to be able to implement a fix or workarround in my app. Should I keep on following this thread? Is there an issue number?

29 Mar 2011, 11:23 AM
If you've subscribed to this thread you'll be notified if sbdy posts here. If it is a very important for your project you can use another form of support, e.g. open a support ticket.

29 Mar 2011, 11:24 AM
I bet it is miframe. I would try using a plain old iframe and see if it breaks.

29 Mar 2011, 11:28 AM
Try using this instead of miframe:

* iFrame panel
* @author Steffen Kamper


Ext.ux.iframePanel = Ext.extend(Ext.Panel, {
name: 'iframe',
iframe: null,
src: Ext.isIE && Ext.isSecure ? Ext.SSL_SECURE_URL : 'about:blank',
maskMessage: 'loading ...',
doMask: true,

// component build
initComponent: function() {
this.bodyCfg = {
tag: 'iframe',
frameborder: '0',
src: this.src,
name: this.name
Ext.apply(this, {

Ext.ux.iframePanel.superclass.initComponent.apply(this, arguments);

// apply the addListener patch for 'message:tagging'
this.addListener = this.on;


onRender : function() {
Ext.ux.iframePanel.superclass.onRender.apply(this, arguments);
this.iframe = Ext.isIE ? this.body.dom.contentWindow : window.frames[this.name];
this.body.dom[Ext.isIE ? 'onreadystatechange' : 'onload'] = this.loadHandler.createDelegate(this);

loadHandler: function() {
this.src = this.body.dom.src;

getIframe: function() {
return this.iframe;
getUrl: function() {
return this.body.dom.src;

setUrl: function(source) {
this.body.dom.src = source;

resetUrl: function() {
this.body.dom.src = this.src;

refresh: function() {
if (!this.isVisible()) {
this.body.dom.src = this.body.dom.src;

/** @private */
setMask: function() {
if (this.doMask) {
removeMask: function() {
if (this.doMask) {
Ext.reg('iframePanel', Ext.ux.iframePanel);

(Found elsewhere on the forums)

Be sure to NOT load multidom.js or anything related to miframe.

29 Mar 2011, 11:59 AM
If so, could the OP send a PM to Dough (the author of miframe) to get his opinion?

29 Mar 2011, 12:09 PM
If so, could the OP send a PM to Dough (the author of miframe) to get his opinion?

The multidom stuff is both clever and evil. It may not at all behave well with another ExtJS library loaded in one of the miframes.

That's my guess about the issue as described.

30 Mar 2011, 5:16 AM
Hello MS,
I've been having another weird problem with MIF (sometimes content inside the iframe appeared grayed-out after been loaded...long storie). But the issue described here happens with plane-iframes as well. In fact, the examples I posted don't use/load MIF or multidom)

30 Mar 2011, 5:29 AM
You might look at trying various hideModes of the TabPanel and Panels:


hideMode : String
How this component should be hidden. Supported values are 'visibility' (css visibility), 'offsets' (negative offset position) and 'display' (css display).

Note: the default of 'display' is generally preferred since items are automatically laid out when they are first shown (no sizing is done while hidden).

30 Mar 2011, 9:41 AM
MS: It was an interesting shot. I just tried changing hidemode to "offsets" and "visibility". Unfortunately, it keeps on doing the same.

30 Mar 2011, 10:46 AM
Did you send a PM to Dough? It think he could shed a light to the problem with miframe, if any.

4 Apr 2011, 11:29 AM
I'll try to explain the MIF problem, maybe in another thread. It's however harder to reproduce and even harder to get an isolated test case (it happens with only one of our programs/pages).

4 Apr 2011, 12:07 PM
If it can be isolate to one page then that page must be somehow different. That means that the moment you find the difference you have it.

24 Jun 2011, 9:40 AM
I recently upgraded my application from Ext-2.2 to Ext-3.4. Now i'm facing the same problem that gyf had. Since the last post of this thread is from a couple of months ago, is there any fix or solution to this bug?

I would appreciate if someone could fix it comment as it did. By the way, I'm not using MIF just plain iframes.


6 Sep 2011, 5:01 AM
Just ran across this thread during Forum patrol... ;)

During development of MIF 4.0: multidom, I encountered this caveat during development of an optimized version of Element.getStyle.

This occurs during framework initialization because a 'presentation' (Computed Style) is not available for IFRAMEs hidden using display:none (including inherited). This is prevalent on all Gecko browsers and Safari (possibly other Webkits as well).

Indeed, if you snoop at the breakpoint (feature detection was introduced in 3.3.1), you'll notice that:

view.getComputedStyle(div.firstChild.firstChild, null) == null (not available)

Possible remedies:

Set deferredRender : false on the tabPanel/Card layout.
If you feel the need to NOT show the tab initially, use the new hideMode offered on 3.3.2+ : 'nosize' (height/width:0) to hide things instead.
Defer setting the src attribute of the frame until the frame's parent Container is rendered (MIF has always used this strategy to minimize such problems), visible, and/or becomes the activeItem of the Layout .

Things get even uglier on IE. On that browser there is only ONE document object -- the one that currently has focus (utter ActiveX rubbish)!

Which makes this:

var DOC = document; risky!

MIF mitigates some of that for you, setting document focus as soon as it detects the document is in a suitable state to do so (and hopefully before Ext thinks the DOM is ready), but that cannot account for the user who's mouse has had just as much coffee as he/she has (impatient tab-switching)! :)

Your success will depend largely on what you're willing to concede in your layouts.

And, no doubt, the feature detection code needs to be strengthened somewhat to account for the lack of computedStyle where appropriate. ;)