Closed Bug 415870 Opened 17 years ago Closed 17 years ago

window.frames[name] persists after iframe is removed from the DOM

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Version:
1.8 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 350023

People

(Reporter: codeexploiter, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11

Hi all,

The problem

I've used innerHTML property of a div element to insert some HTML text into it. The HTML text has an <iframe> element which loads another HTML (local) page. The page loaded in the iframe has a <script> section in which I have a JavaScript variable which is initialized properly.

My first page has 3 buttons in it. The first button (Add) will add the HTML into an existing div element. The second button (Remove) will empty the div element's contents using innerHTML and the third button will show the JavaScript variable which is in the second page loaded in the iframe.

(1) I've loaded the page

(2) clicked Add button - it inserted the content (HTML) successfully

(3) Clicked Show button - It displayed the JavaScript variable correctly

(4) Click Remove button -  It emptied the div element using innerHTML property

(5) Immediately after the emptying of div container I've put an alert which tried to make sure that whether the iframe which is inside the div which has just been emptied I found that the iframe object still exists, which is not correct.

(6) After the removal I've again performed Add and it worked correctly as it supposed.

(7) Then when I tried to access the JS variable it displayed the result as undefined which is wrong.

This is the problem I am facing and this problem experienced in Mozilla Firefox (2.0.0.11) and Flock (1.0.8). I've tried some other browsers in which this works correctly I mean when you empty the div element using innerHTML then the child iframe object is also removed correctly. The browsers are MSIE 7.0, Opera 9.25 and Safari for windows 3.0.4.

Please find the code below using which you can reproduce the problem

Filename 2.htm
--------------------

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
	<head>
		<title> </title>
		<style type="text/css">
		
		</style>
		<script type="text/javascript">
		
		var add = function(){
			var str = "<div><iframe frameborder='0' width='300' height='100' src='1.htm' id='ifr' name='ifr'></iframe></div>"		
			document.getElementById('main').innerHTML = str;
		}
	
		var remove = function(){
			document.getElementById('main').innerHTML = '';
			alert('After emptying the innerHTML of the container the frame is '+ window.frames['ifr']);
		}
			
		var show = function(){
			if(window.frames['ifr'])
				alert(window.frames['ifr'].myvar);
			else alert('frame is not present');
		}		
		</script>
	</head>
	<body>
		<div id="main">
			
		</div>
		<form name="f1">
			<input type="button" value="Add" onclick="javascript: add();"/>
			<input type="button" value="remove" onclick="javascript: remove();"/>
			<input type="button" value="show" onclick="javascript: show();"/>
		</form>
	</body>
</html>


Filename : 1.htm
----------------------

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title> </title>
<style type="text/css">
	
</style>
<script type="text/javascript">
var myvar = 1000;
</script>
</head>
<body>
<h1>3.htm</h1>
</body>
</html>

Steps
---------
1. Save both files in the same folder

2. Load the first file (2.htm) in your Firefox browser.

3. Click Add

4. Click Show

5. Click Remove - Here I have an alert through which you can see the status of the iframe object after the div element emptying via innerHTML

6. Click Add - 2nd time

7. Click Show - It will display the value of the javaScript variable as undefined which is not correct.

I can avoid this problem If I reload the page when I empty the div element but in my case I am dealing with a web page which is heavy and have a large number of AJAX calls involved and I would like to have a method without page reloading.

Thanks for your help

Regards

Codex

Reproducible: Always

Steps to Reproduce:
1. Save both files I mentioned above in the same folder
2. Load 2.htm and click on Add, Show and Remove buttons respectively
3. Click again on Add and Show buttons respectively
Actual Results:  
After the second step in which I've loaded the div with some HTML, displayed the JS variable of a page loaded in an iframe and removed these elements by emptying the innerHTML of the div element. After the emptying I found that the removed iframe object still exists.

In the 3rd step of the above mentioned Add button click worked as it supposed. But the Show button click displayed undefined as an alert which is incorrect as it should be 1000 according to my code provided.

Expected Results:  
The iframe object should be removed when I empty the div element using innerHTML.

It should display the JavaScript variable correctly as 1000 according to my code
Version: unspecified → 2.0 Branch
Component: General → DOM: Mozilla Extensions
Product: Firefox → Core
QA Contact: general → general
Version: 2.0 Branch → 1.8 Branch
The DOM tree is fine; it's just that window.frames['...'] is lying to you.  This is probably a dup of bug 170799.
Component: DOM: Mozilla Extensions → DOM: Level 0
Summary: iframe object is not removed from the DOM after emptying the parent container's innerHTML property → window.frames[name] persists after iframe is removed from the DOM
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.