Am I missing something obvious or does anybody else have any problems with the height of the IFrame Module in DNN?

I have set both the width and height to 100%, There is nothing else on the page other than the usual DNN header and footer. I am still using the original DNN 'Skin' so I am at a loss to see what the problem is?

Any help greatly appreciated.

The iframe height and width works fine. Perhaps you've got your iframe inside of a container or other table that is NOT set to 100%?

My hunch is that this problem is related to your skin and not the iframe.

However, on that note, I've used the following code to dynamically set the height:

In the "Width" option try: 100%
In the "Height" option try: 388" style="height:expression(document.body.clientHeight-358);"

Again, that's:

388" style="height:expression(document.body.clientHeight-158);"

quotations and all!

What this does is set the height of the iframe to 388. Then the module inserts the 'style' expression to dynamically set the height of the iframe to the height of the browser window - 158 pixels (leaving some room for the toolbars etc.). You'll want to play with these numbers according to your own skin.

Keep in mind that this is a little unorthodox but the finished product (once DNN inserts the iframe into the page) is:

<iframe frameborder="no" src="http://mypage.com/framedpage.asp" height="388" style="height:expression(document.body.clientHeight-358);" width="100%" title="GuestBook" scrolling="auto">

You can see a live example at http://www.md23libraryboard.ca (visit the 'guestbook' page).

Cheers

One caveat...dynamic iframe resizing (as in the example Sabine posted) will only work if the iframe URL is in the same domain as the container page. It it's not, built-in browser security prevents the clientHeight property value from being read.

Nik

I disagree that height and width works fine Dave and it's been a problem since DNN 1. You'll notice he's got height and width set to 100% and that's never worked for the height of an iframe. In DNN 1 it was an easy fix by adding a height tag to the container module but that isn't possible in DNN2 (and I haven't found an easy fix in editing any skin's .ascx file).

However, I haven't tried your your solution but I'll give it a shot as I've got some dynamic pages on my site.

Hello mikeh36,

I agree that the iframe module could be improved, perhaps to include a 'style' reference. a la:
Width: ____
Height: ____
Style: ____

Then my 'workaround' would make more sense and it wouldn't feel like I'm trying to trick the module into working it the way I want. :)

Defining a height of 100% for any iframe (within DNN or not) has always rendered unpredictable results in my experience. I have found that it's usually better to define a 'default' height using a literal value (such as "400" or "400px") then use CSS to dynamically resize the iframe in the browser. This way, browsers that support dynamic CSS will render the page exactly as you intend, and other browsers will render a reasonable 'compromise'. (the compromise that I aim for is for the lowest common denominator, like old Netscape on an 800 x 600 screen.

I haven't experienced the browser security issue that cniknet mentioned. (although i haven't used iframes frequently in multiple-domain settings.) cniknet, Which browser? and does the problem occur only where different domains are used? and what if the two different domains are served from the same server/IP address?

I ask because in my case, the DNN portal is served from 'www.md23libraryboard.ca' and the framed page is served from 'xnet.md23libraryboard.ca' (different Zone in the same domain) and i haven't experiened the problem you mentioned. As well, during the development of the site, I served the DNN portal from a 'temp' domain and framed the other page (in the other domain) without problems.

Cheers.

Sabine,

Many thanks, that worked a treat.

Apologies, I spoke out of context. The browser security issue occurs when you use script to stretch the iFrame to always prevent the display of scroll bars. For example, in the page sample below, I want the user to be oblivious that the content is in an iFrame. Using this script, as long as the iFrame container page and the iFrame document page are in the same domain (i.e. same or different hosts in the same domain), the code works and the iFrame never displays vertical scroll bars. However, when the iFrame document is in a different domain, browser security (IE & Netscape), will not allow the contentWindow properties to be accessed. I work around this by trapping the security error and setting the iFrame height to a fixed value in those situations.

<html>


<head>


<script language="Javascript">


function stretchIFrame(frameName,minHeight)


{


    	contentHeight = 0;


	try


	{


	   contentHeight=document.getElementById(frameName).contentWindow.document.body.scrollHeight+50;


	}


	catch(err){}


	if (contentHeight < minHeight) contentHeight = minHeight;


	document.getElementById(frameName).style.height=contentHeight;


}


</script>


<iframe id="myframe" frameborder="no" src="http://www.dotnetnuke.com" height="1" width="400" title="DotNetNuke" scrolling="auto" onload="stretchIFrame('myframe','100')">


</iframe>


</html>

cniknet,

This IS interesting.

I think that the security problems you're experiencing are due to the fact that you're trying to read properties from the 'framed' page with javascript in the parent.

document.getElementById(frameName).contentWindow.document.body.scrollHeight+50;

This procedure seems to ME to be a likely candidate for security concerns. If this were possible in a cross-domain setting, than it might be possible to execute script, call javascript functions, and trigger events in the sub-frame's document. If your script were possible, then I might be able to, say:

document.getElementById(frameName).contentWindow.document.document.attachEvent("onmousemove", popopen_a_maliciousWindow_function);

and your browser might execute the "popopen_a_maliciousWindow_function" from within the framed document's event bubble.

Or even worse, I might be able to rewrite the document.body.innerHTML to contain my own content.

I *think* I understand what you're trying to do though and it makes sense from a logical standpoint:

1. you want to know the height of the framed document's content, so that
2. you can create the iframe to be slightly taller! hence avoiding any scrollbar, yet you can keep the iframe as 'short' as possible so that it requires minimal vertical space on your page.

am I on the right track?

But the scrollHeight property is only reliable with content embedded within the same document. (Like checking the height of viewable content in a div on the same page). I can see where this may fail in iframe situations.

In any case, my earlier example is merely a method to make an iframe as tall as possible while preventing a scrollbar in the PARENT window - where I don't mind a scrollbar on the iframe itself. And just for the sake of example, this could be achieve with your javascript example by altering this line:

//contentHeight=document.getElementById(frameName).contentWindow.document.body.scrollHeight+50;

contentHeight=document.body.clientHeight-(document.getElementById(frameName).offsetTop+20);

cheers.

So Dave, to extend that to your first example would it then be:

388" style="height:expression(document.body.clientHeight-(document.getElementById(frameName).offsetTop+20);"

so that you stretch the iframe the full length of the document and don't have scrollbars showing up on the frame?

Hello mikeh36,

I think you've got it wrong. But I'm not sure what you're trying to accomplish exactly...so...

if you want to combine my trick with cniknet's trick, then you'd type this:

388" style="height:expression(contentWindow.document.body.scrollHeight+50);"

This will produce a window that is 50 pixels taller than the 'contents' of the child frame. But, keep in mind that this will only work IF the page in the child frame is located in the same domain as the parent page. If you try to frame a page that is from a different domain, then the web browser's security features will prevent it from working.

Cheers.

Thanks Dave, That's what I was looking for. I never was much for Javascript :)

I haven't liked javascript either and have had difficulty learning how to use it effectively, but alas we're stuck with having to manage cross-browser compatibility and Javascript is well supported by most browsers.

the hardest parts about writing javascript (in my opinion) are two things:

1. I find that the native functions are difficult to understand and remember. First their names and secondly their arguments aren't as intuitive as other client-side scripting environments. For example, "indexOf" just doesn't make as much sense to me as the VBScript "Instr", and VBscript has great tools for working with dates and data conversion while these things seem 'clumsy' to me in javascript.

2. its syntax sometimes bothers me.


Anyways...a couple of essential references:

http://www.devguru.com/Technologies/ecmascript/quickref/javascript_index.html

and (for scripting in IE only)

http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/reference/dhtml_reference_entry.asp

I use these two resources on a daily basis. (In only wish that Opera, Safari, Netscape, and others had a comprehensive object and language reference like the MSDN site above!)

Cheers.

Thank you for the great information. I am having problems with Iframe width. I am getting very unexpected results setting px and %. Is there a trick for the width like the one you posted for the height?

Thanks

Hello skunk,

I'm not sure what you're trying to accomplish? And what sort of results are you getting now with px and %?

If I use the script:

388" style="height:expression(contentWindow.document.body.scrollHeight+50);"

I receive "Runtime Error: object required" if my browser is NOT configured to "disable script debugging" (in IE : tools/internet options/advanced/disable script debugging not checked. Is this normal?