(Firefox only) hidden iframes can throw exceptions when testing dojo._isBodyLtr()

[guest]

the dojo._isBodyLtr() is added to my custom code base when I build (presumably by dijit), i'm not sure where this added:

if(!dojo._hasResource["dijit._base.bidi"]){ //_hasResource checks added by build. Do not use _hasResource directly in your code.
dojo._hasResource["dijit._base.bidi"] = true;
dojo.provide("dijit._base.bidi");

// summary: applies a class to the top of the document for right-to-left stylesheet rules

dojo.addOnLoad(function(){
	if(!dojo._isBodyLtr()){
		dojo.addClass(dojo.body(), "dijitRtl");
	}
});

In anycase when this is called the subsequent dojo._bodyLtr = dojo.getComputedStyle(dojo.body()).direction == "ltr" returns null on an iframe that is wrapped in a hidden div (see attached test files).

[guest]

For some reason my email doesn't remain in the form it's (ialpert at coemergence dot com). To use the test load hiddenIframe.html in firefox with test.html in the same directory (test.html is the source of the iframes used in hiddenIframe.html). You'll probalby have to change the location of the dojo libraries

[guest]

Might be related to #5142: dojo.style, undefined or null error

[bill]

Yeah, getting style on hidden nodes doesn't work well so this is probably a "wonfix" (or "cantfix"). You should try on FF3 to see if it works better there.

[guest]

Maby a reasonable fix for this is a null guard in the calling code {{{ dojo._isBodyLtr = function(){

//FIXME: could check html and body tags directly instead of computed style? need to ignore case, accept empty values return !("_bodyLtr" in dojo) ?

dojo._bodyLtr = dojo.getComputedStyle(dojo.body()).direction == "ltr" : dojo._bodyLtr; // Boolean

}

}}}

[guest]

Replying to bill:

Yeah, getting style on hidden nodes doesn't work well so this is probably a "wonfix" (or "cantfix"). You should try on FF3 to see if it works better there.

I am seeing a similar problem as the original poster - I have a TabContainer? where each "tab" is a ContentPane? with no content originally. When my app runs, each ContentPane? gets the content set with an iframe (which has a src tag).

This all ran perfectly fine in 0.4.3, but I am now upgrading to 1.0.1 and when my first frame is being loaded (it is not the selected frame), I am getting the error:

dojo.getComputedStyle(dojo.body()) has no properties

dojo._bodyLtr = dojo.getComputedStyle(dojo.body()).direction == "ltr" :

(for me it's in dojo.js.uncompressed.js line 4306).

and my dojo.addOnLoad function is never getting called so my code does not initialize properly.

This is a pretty severe problem and I don't see any workaround except hacking away at the dojo source code. Is there any chance that someone else has a workaround or that we'll get a solution soon?

If possible, I'd like to be added to the cc on this bug (stenduncan @ gmail dot com)

[bill]

Stenduncan - I'm wondering why you need to use iframes in the first place, since ContentPane? has similar functionality to an iframe, with href loading. But if you need to use an iframe for each tab, then why don't you just wait to load each tab until the user selects it? (ie, lazy loading)

[peller]

so a related issue is whether this code in dojo.loaded (loader.js) should have a try/catch on each iteration:

		for(var x=0; x<mll.length; x++){
			mll[x]();
		}

[guest]

Replying to bill:

Stenduncan - I'm wondering why you need to use iframes in the first place, since ContentPane? has similar functionality to an iframe, with href loading. But if you need to use an iframe for each tab, then why don't you just wait to load each tab until the user selects it? (ie, lazy loading)

Bill, you're absolutely right, I probably don't need iframes and I'm going to be changing that in the future. But I am doing a straight port from 0.4.3 to 1.0.1 at the moment and I smashed into this. I don't have time to rewrite my entire app just now.

I've edited my copy of the Dojo code directly (I hate doing that) to make sure I don't get that error any more, but I'd love to hear that this has been fixed in the real code.

-- stenduncan

[peller]

(In [11852]) put onload trigger in try/catch so a failure doesn't kill the bootstrap. Refs #5197

[alex]

Milestone 2.0 deleted

[peller]

(In [12776]) add more descriptive error message for onload failure. Refs #5197