I created a prototype.js/window.js "Window" pseudo window div with another page from the same directory loaded in its iframe

I could not put a button/link on the iframe doc that would close it by calling functions in the parent window

I used "window.parent" "parent" alone "top" but the only thing I could access from the iframe was the window.parent.location property

I ended up constructing the Window by writing the content to it from the main page, not loading a url in the iframe

But it bugs me that I couldn't access the parent window functions (or anything, getElementById didn't work either, so Window method $('Window_ID').close() wouldn't work either)

any ideas?

Why not just create a normal window? The child window holds a reference to the parent window which created it in the form of 'opener' property. Here 'opener' is the window object of the parent window.

Parent.html

<html>
<head>
	<script>
	function go() {	
		window.open("Child.html");
	}
	</script>
</head>
<body>
<form name="frm">	
	<input type="text" value="Hello" id="txt" name="txt" />
	<input type="button" name="btn" id="btn" value="Button" onclick="go();" />
</form>
</body>
</html>
Child.html

<html>
<head>
	<script>
	function go() {
		alert(opener.document.forms[0].elements["txt"].value);
	}
	function change() {
		opener.document.forms[0].elements["txt"].value = "This is changed text";
    opener.focus();
		this.close();		
	}
	</script>
</head>
<body onload="go();">
	<form>
		<input type="button" value="Change Value in Parent" id="btn" name="btn" onclick="change();"/>
	</form>
</body>
</html>

That's why I specified it is a prototype.js/window.js pseudo window (actually a floating div)

Reasons to use this "Window"

1. It can be themed more completely than a standard window.

2. Since it is a div on the page, it does not get blocked by pop-up blockers.

3. I was called in as a special consultant to "make JavaScript stuff work" and the pseudo window already existed - I could have changed it, or even used a simpler pseudo window, but I wanted to make the status quo work.

example: http://philosophersguild.com/test_site/index.lasso

Where I wrote the div content from the main page (pseudo-opener) using a window.js method getContent().innerHTML rather than loading the div content in an iframe (also using a native window.js method/constructor) from a HTML file, as a solution to the problem. However, in this solution, I was unable to use the JS Flash loader script and had to load the Flash with HTML.

But I still don't understand why the only property on the parent window I could access from the iframe was location...

I was so disappointed to read your reply, I thought somebody could illuminate the quirks of prototype.js/window.js

To me, your example is unnecessarily verbose, you should use ids to shorten the DOM path of elements. I would also recommend using the definition type="text/javascript" in your script tags for future compatibility. And reusing the function name "go" on the child window, while demonstrating the independence of functions on opener and child, is a great way to get confused. Try to use more descriptive function names, "go" is quite generic. I like the name "change"

In the prototype.js environment you can write document.getElementById('idvalue') as $('idvalue') so I'm sure you can understand the simplicity/productivity increase inherent in using the libraries.

prototype.js/window.js is a very popular library in widespread use but I am interested in discovering its limitations as well as its possibilities.

Here is another window.js test, notable for the advanced debug window object/property inspector (no, you really gotta try it out!):

http://philosophersguild.com/test_site/windows_js_test.lasso

I do a lot of work with PHP, and passing values between PHP and JS, and on this site, passing values between Lassoscript and JavaScript.

Personally, I prefer cooking my own code too, but I am impressed by some aspects of the prototype.js library and baffled by why something simple like an iframe close Window (or hide div, as it were) doesn't work.

I have been writing JavaScript since the days when you had to sniff out Netscape2 because IE3 had superior JS support... in other words, a long time.

> I was so disappointed to read your reply, I thought somebody could illuminate the quirks
> of prototype.js/window.js

I am pretty sure that the quirks of prototype.js can be better explained by the people *at* prototype.js message board; this board is more focussed on general Javascript discussion.

> To me, your example is unnecessarily verbose,

I keep my examples extremely verbose and simple so that beginners don't have a problem understanding them and I had no way of knowing that you had experience with Javascript. I could have added loads of checks but at the cost of confusing the newbies. I am also missing a DOCTYPE but that's a different story altogether...

> In the prototype.js environment you can write document.getElementById('idvalue') as
> $('idvalue') so I'm sure you can understand the simplicity/productivity increase inherent in
> using the libraries.

And what about the people who has just started Javascript? I very well understand the productivity increase / decrease when using Libraries but don't want to drag it all here when there are people people out there struggling with the basics of Javascript.

> you should use ids to shorten the DOM path of elements

I disagree; I would rather pick up ready made references from the 'elements' HTMLCollection than traverse the DOM for a trivial task like getting a reference to a form element...

> I have been writing JavaScript since the days

I am sure you have been in this industry for long enough to know that no one gives a hoot as long as you deliver the goods. :-)

I would make sure I post it here if I find something of use to you.

Well, I appreciate your comments and I understand it's tough to keep code understandable to novices.

Yes, your example is clear (except maybe for the two distinct go() functions), but I would not want to access form 9 that way (or is it 10? or let's try #8...) especially if any dynamic processes/scripting etc may be changing the number of forms based on parameters - I think you know what I mean :~)

I just finished the logic on a MySpace-styled search page which displays various forms and interfaces depending on criteria, I couldn't have done it without assigning the display property dynamically to id'd sections.

I did deliver on this one too, by using a different method to load the content, but as an obsessive type, it bothers me that I could not access the window.parent objects/properties/methods except for location, so I know I was accessing the right window (and I mean window in this case, not pseudo-window)

And I found this forum by searching for prototype.js and window.js so this was not a random post, I figured people here know what's going on (and I guess they do!)

You should check out that debugger/property inspector that was a hack on window.js but now included with the official release, it's really quite impressive and useful - I know, I have lots of web dev plug ins for FFox, but this reinvention of the wheel rocks and rolls!

Finally, I appreciate your offer to keep your eyes open on this one, and if I find an answer I will post back to close the issue.

I'm still looking for the answer, how to close/hide the "Window" from the iframe?

This worked for me.....in the caller:

var closeWindows = function() {
	Windows.closeAll();
}

And in the iframed page:

window.parent.closeWindows();

this looks like it could work, didn't try nesting the function

The page with the iframe no longer exists but I will keep in mind for the future

thanks

I also posted this question on LinkedIn if you want to answer there for rating

To close a window from it's child iframe:

//check to see that parent has the Windows class
//and that I am acutally in a frame (thus i have frameElement)
//we check for frameElement so that it doesn't crash if this 
//page is opened outside of an iframe.
if(parent.Windows && frameElement) {
   var mydiv = $(frameElement).up("div");
   var mydivid = mydiv.id;
   var win = parent.Windows.getWindow(mydivid);
   win.close();
}

basically parent is the parent browser
global variables are accessed from the parent object, so parent.Windows in the iframe is the same as Windows in the parent

the added benefit of parent is that if you are just in a browser (no iframe), then parent points to yourself and all your global variables.

Now, I need to know how to access the variables of the child from the parent.

Just briefly before I left work, I found that [iframe].contentWindow gives me access to the iframes variables on IE7 and FF3. Not sure about lesser browsers.

so...

<iframe id="myframe" src="abc.html">

//assume abc.html has the window class installed along with prototype
$("myframe").contentWindow.Windows.getWindow("theWindow").close();
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.