Advertisement
Web Developer Resources
You Are Here: ESQSoft.com ¬ javascript_examples ¬ iframe_talks_to_parent ¬ JavaScript Help: How to access parent elements from a child window or frame
E.S.Q. Software Logo

JavaScript Help: How to access parent elements from a child window or frame

This example shows how to use JavaScript to access parent elements from within a child, and vice versa. I'll demonstrate how to get or set a value in the child, from the parent, or in the parent, from the child. The trick is getting a reference to the target container, and then knowing enough about the DOM in that target to access the specific element you are after. While this example uses an IFRAME, the mechanism, and rules apply to child windows and frames as well, though getting the attachment to the target "window" object may require some tweaking. (If you have a specific example this doesn't work for, please share, I'll see if I can suggest a method. Thanks.)

The example shows a form in this page (which is the parent in our example.) Two IFRAMEs load the same page from different URLs. The first IFRAME's child page comes from another page on this domain. It's JavaScript can then access elements in this page for reading or writing. The second IFRAME child comes from a different domain. While the page is the same, because of a cross-domain scripting security rule in JavaScript, that child cannot read or write to DOM elements in the parent (this page).


Example: The "parent" form is displayed between the local (same domain) and remote (different domain) frames. Try modifying the value in the parent form and seeing if you can have the local or remote child get the value. One will work, one will result in an error. Then try altering the value of the test data in each of the children and seeing if you can set the parent data from the child. Again, one will work, one will result in an error.
(IFRAME container)
Test data:
(IFRAME container)

Related Issues

Cross-domain/Same Origin Policy Issues There is a browser security rule regarding cross-domain scripting (called the same origin policy) that often becomes an issue in these scenarios. When a parent and child come from the same domain, they have access to each other; the child can access and operate properties and methods of the parent, and vice-versa. However, when they don't, attempting such access so will trigger script errors indicating Permission denied. To illustrate, our example uses parent.document to access pieces from the caller's document object model. When the parent and child are on the same domain it works fine, but when they are on different domains you the "permission denied" script error occurs. This problem is very common these days where external resources often reside on a different domain than the code using it. This will certainly result in error messages and functionality that fails to behave as intended. So, how can we fix these kinds of problems? Here are some suggestions for getting around cross-domain same origin policy issues:

  1. Same domain -- Well, first off, -IF- you can get everything on the same domain, that's the optimal scenario--because it's the simplest; everything will "just work" automatically.
  2. Proxy -- Since same-domain is usually not feasible you may want to create a proxy to basically fool the browser into thinking the content comes from the same domain (while this sounds nefarious, sadly this is common-place in many AJAX applications today pending a better solution).
  3. JSONP -- If you have access to both domains, you may be able to set up a scenario in which the output of your requests basically get wrapped in a mechanism that causes them to be instantiated in such a way that the same origin policy doesn't get applied. Personally this situation has been rare for me so I don't use this, however, you can find more info about JSONP here.
  4. Try/Catch error handling -- If none of these fit the bill, and you are willing to accept that sometimes your scripts will work and sometimes they wont, then you may want to use TRY/CATCH with your script in order to control and gracefully handle the behavior when something goes wrong and an error occurs. This can be complicated if you aren't accustomed to building code in anticipation of unexpected failures--pretty common in my experience.
In case you wonder how often these errors occur, here are some common related errors that happen even from some of the web's most technical and/or respected companies:
  • Error: Permission denied for  to call method Location.toString on .
  • Error: Permission denied for  to call method UnnamedClass.toString on <>.
  • Error: parent.YAHOO is undefined
  • Error: Permission denied for  to call method Location.toString on .
  • Error: Permission denied for  to call method Location.toString on .

Using Try/Catch/Finally to Control JavaScript Errors Whether you experience cross-domain problems or not, it's good practice to expect the unexpected, and code in such a way that your errors are caught and handled gracefully if possible. Because JavaScript is an interpreted language; the javascript source code appearing in an HTML response for example, is handed off by the web browser during rendering and run by a JavaScript engine that is integrated into the browser. When something goes wrong, that engine returns an error to the browser and consequently the browser reports the error to the visitor. Some browsers do this more quietly than others, but if your scripts are built so that subsequent operations assume that earlier operations succeeded then your visitors are going to see non-functional, broken applications. Maybe you don't think this is a big deal, but when I tried to log in to my bank after they updated to JSPs and a javascript error actually prevented my form submission from being sent at all, you can imagine that I was angry--and I knew how to get around the problem; I spoofed the submit. When it's someone who isn't a web developer, that's even worse; you've sunk them. If you are new to JavaScript, errors are reported in the lower left of the browser window in Internet Explorer; look for a small icon (when you attempt an operation which results in an error, that error is returned to your browser. For Internet Explorer you'll see an error icon appear at the bottom of your browser. If you want to see the details of the error, you need to double-click that icon to display the details. If you are using Firefox, you'll need to type "javascript:" in the address in order to pop open the console where you can view the error. I'm not sure how to do this on a Mac, or Linux, or other browsers. (I'd love input if anyone wants to share. Thanks.) In this example, I've defaulted the operations to go through the JavaScript TRY and CATCH error handlers. This means by default, operations that result in an error should be handled in a controlled manner, and instead of seeing nothing, you'll see an alert which indicates an error happened.

Author: Thomas Ballard.

related keywords: permission denied, parent.document, access dom elements in parent child relationship