Keywords: Internet Explorer | iframe | document.domain | same-origin policy | JavaScript error
Abstract: This article provides an in-depth analysis of the "Access is denied" JavaScript error encountered when dynamically creating iframe elements in Internet Explorer browsers. When the parent page sets the document.domain property, IE blocks access to the document object of src-less iframes due to implementation differences in same-origin policy enforcement. Based on the best answer, the article presents solutions using javascript:URL as the src attribute, discusses their limitations, and addresses cross-browser compatibility considerations. Through code examples and technical analysis, it offers practical guidance for developers facing this classic IE compatibility issue.
In web development, using iframe elements to create isolated sandbox environments is a common practice, particularly when developing widgets that need to be embedded in third-party websites. By dynamically creating iframes and directly injecting content into them, developers can avoid CSS and JavaScript conflicts while maintaining independence from the parent page. However, this seemingly straightforward operation can encounter unexpected obstacles in Internet Explorer browsers.
Problem Description and Reproduction
When the parent page sets the document.domain property, dynamically creating an iframe element without a src attribute in Internet Explorer (including versions 6, 7, and 8) results in an "Access is denied" error when attempting to access its document object. Other modern browsers like Chrome, Firefox, and Safari handle this situation normally.
The following code example reproduces the issue:
<script type="text/javascript">
document.domain = 'example.com';
var iframe = document.createElement('iframe');
document.body.appendChild(iframe);
setTimeout(function() {
var doc = iframe.contentWindow || iframe.contentDocument;
// In IE, the following access throws "Access is denied" error
if (doc.document) {
doc = doc.document;
}
doc.body.innerHTML = '<h1>Hello World</h1>';
}, 10);
</script>Root Cause Analysis
The fundamental cause of this issue lies in Internet Explorer's unique implementation of the same-origin policy. When the parent page sets the document.domain property, IE assigns a document.domain value to dynamically created src-less iframes based on the parent page's location.host, rather than inheriting the parent page's document.domain setting. Due to the mismatch in document.domain values, IE's security mechanism blocks access to the iframe's document object.
More specifically, IE's same-origin policy implementation requires all windows or frames that need to communicate with each other to have identical document.domain values. For dynamically created iframes, developers cannot modify this property without access to the document object, creating an access barrier.
Solution: javascript:URL Approach
Based on the best answer, a viable solution involves using a javascript:URL as the iframe's src attribute. This approach allows JavaScript code execution during iframe initialization, providing an opportunity to set the document.domain property.
Basic implementation code:
var iframe = document.createElement('iframe');
iframe.src = "javascript:'<html><body><script>document.domain=\"" + document.domain + "\";<\/script></body></html>'";
document.body.appendChild(iframe);However, this method has an important limitation: in IE, documents created directly via javascript:URL cannot modify their own document.domain property through script. This results in an "unspecified error," preventing the iframe from establishing communication with the parent page.
Enhanced Solution: document.write Technique
To overcome this limitation, an indirect approach can be employed: first create an initial document containing a document.write call, then use that call to write a second document where the document.domain property is set.
Implementation code:
if (isIE) {
var iframe = document.createElement('iframe');
iframe.src = "javascript:'<script>window.onload=function(){document.write(\\'<script>document.domain=\\\"" + document.domain + "\\\";<\\/script>\\');document.close();};<\/script>'";
document.body.appendChild(iframe);
}This technique leverages an IE-specific behavior: while documents created directly via javascript:URL cannot modify document.domain, a second document created via document.write can successfully set this property. This enables the iframe to establish proper communication channels with the parent page.
Cross-Browser Compatibility Considerations
It's important to note that the javascript:URL approach is not supported in Safari browsers. Therefore, in practical applications, browser detection must be combined with appropriate implementation selection.
A complete cross-browser solution might look like this:
function createIsolatedIframe(content) {
var iframe = document.createElement('iframe');
if (isInternetExplorer()) {
// Use javascript:URL approach for IE
iframe.src = "javascript:'<script>window.onload=function(){document.write(\\'<script>document.domain=\\\"" + document.domain + "\\\";<\\/script>\\');document.close();};<\/script>'" + content + "'";
} else {
// Use standard approach for other browsers
document.body.appendChild(iframe);
var doc = iframe.contentDocument || iframe.contentWindow.document;
doc.open();
doc.write('<script>document.domain="' + document.domain + '";<\/script>' + content);
doc.close();
}
document.body.appendChild(iframe);
return iframe;
}Alternative Approaches and Additional Recommendations
Beyond the methods discussed, consider using external HTML files as the iframe's src. This approach is more straightforward and offers better compatibility:
iframe.src = '/widget-template.html#' + document.domain;In the external HTML file:
document.domain = location.hash.substring(1);Advantages of this method include better code organization, clearer separation of concerns, and improved browser compatibility. Disadvantages include additional HTTP requests and potential deployment complexity.
Conclusion and Best Practices
The key to solving dynamic iframe access issues in IE lies in understanding browser implementation differences in same-origin policy enforcement. For iframes that need to communicate with parent pages, identical document.domain properties must be ensured.
In practical development, consider:
- Prioritizing external HTML file solutions unless specific constraints exist
- Implementing comprehensive browser detection and fallback mechanisms if dynamic content injection is necessary
- Avoiding modification of
document.domainproperties when possible to reduce compatibility issues - Thoroughly testing all target browsers, particularly different versions of Internet Explorer
By understanding these technical details and selecting appropriate implementation strategies, developers can create iframe sandbox environments that function correctly across all major browsers, including Internet Explorer.