parentNode property of removeChild'd elment object in IE6+7

O

OttoA

Hello,
I was creating a transparent cover-div for my interactive content to
prevent the user clicking all kinds of trouble during xhr-loads, when
I discdovered that IE (at least 6 and 7) did something unexpected. My
idea was to hang on to the cover-div once it's created, and then to
remove it/place it over the content as needed. As I was checking its
in place/removed status only by looking at the existence of the cover-
div's DOM-object's parentNode I found that after a
coverdiv.parentNode.removeChild(coverdiv)-operation the coverdiv,
instead of having null for its parentNode, had a documentFragment for
a parent.

I was expecting it to be null, and later found that at least David
Flanagan's book concurred, as did the other browsers.

Now obviously this is not a hard thing to remedy, I'm just curious
whether this is a known issue (perhaps a feature?) and to check that
I'm not just missing something obvious. The test code below worked
fine in (windows versions of) FF 3, Chrome and Opera 9 (except for the
transparency in Opera, but that's a different matter). I couldn't find
any references to this in msdn, Quirksmode, or by general googling, so
at least it doesn't seem to be documented.

Thanks in advance for any comments/suggestions etc.

-OP

and the code:

<html><head>
<script type="text/javascript">
var Glob = {};
function toggle() {
if(!Glob.d) {
Glob.d = document.createElement("div");
Glob.d.className = "trans";
}
alert("Glob.d's parent before: "+
(Glob.d.parentNode ?
Glob.d.parentNode.nodeName : Glob.d.parentNode)
);

if(Glob.d.parentNode){ Glob.d.parentNode.removeChild(Glob.d); }
else{ document.body.appendChild(Glob.d); }

alert("Glob.d's parent after: "+
(Glob.d.parentNode ?
Glob.d.parentNode.nodeName : Glob.d.parentNode)
);
}
</script>
<style type="text/css">
div.trans {
background-color: #FFF;
filter: progid:DXImageTransform.Microsoft.Alpha(opacity=30);
background: rgba(255,255,255,0.3);
position: absolute;
width: 700px;
height: 400px;
border: 1px solid black;
z-index: 99;
top: 40px;
}
</style>
</head>

<body>
<button onclick="toggle()">toggle</button>
<div>
<p>Test content, should be covered by a transparent cover div.</p>
<p>This will make all content unreachable to mouseclicks, such as <a
href="www.google.com">links to places</a>.</p>
<p>Final paragraph of text.</p>
</div>
</body></html>
 
D

David Mark

Hello,
I was creating a transparent cover-div for my interactive content to
prevent the user clicking all kinds of trouble during xhr-loads, when

That won't stop them from pressing keys (e.g. tab). ;)
I discdovered that IE (at least 6 and 7) did something unexpected. My
idea was to hang on to the cover-div once it's created, and then to
remove it/place it over the content as needed. As I was checking its
in place/removed status only by looking at the existence of the cover-
div's DOM-object's parentNode I found that after a
coverdiv.parentNode.removeChild(coverdiv)-operation the coverdiv,
instead of having null for its parentNode, had a documentFragment for
a parent.

I was expecting it to be null, and later found that at least David
Flanagan's book concurred, as did the other browsers.

Per usual, Flanagan is a bit off and IE a bit odd. If the element has
an ID, try to fetch it with gEBI. Now *that* will return a null if
the element has been removed from the document.
 
V

VK

 If the element has
an ID, try to fetch it with gEBI.  Now *that* will return a null if
the element has been removed from the document.

How much do you bet on it? ;-)

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<title>Test</title>
<script type="text/javascript">
var p = null;
window.onload = function() {
p = document.getElementById('foo');
document.body.removeChild(p);
window.setTimeout('window.alert(p)',100);
// will show HTMLParagraphElement
// like never nothing
}
</script>
</head>
<body>
<p id="foo">foo</p>
</body>
</html>
 
O

OttoA

Hi VK,
David can surely respond for himself, but your example is not doing
what he suggested.

 If the element has
an ID, try to fetch it with gEBI.  Now *that* will return a null if
the element has been removed from the document.

How much do you bet on it? ;-) [...]
<script type="text/javascript">
 var p = null;
 window.onload = function() {
  p = document.getElementById('foo');
  document.body.removeChild(p);
  window.setTimeout('window.alert(p)',100);

Your var p has a ref to the DOM node-object, which won't be destroyed
even if it's not in the document itself, at least with a reference to
it still alive.

My original question was to find a reliable way to check whether an
element is *currently in the document* and the whole point was to not
destroy the element once it's created, just take it out of the doc and
to insert it back again later.

I'm sure that in your example alert() would result in 'null' if you'd
used getElementById(), not the reference to the DOM-object.

And David, thanks for the idea, although I'm not sure yet whether I'll
use that or just create a 'isLoading' global variable, and toggle that
at the same time as the element in the function. That would make for
one less function call..

-OP
 
V

VK

Actually I am wondering if UA producers provided any native means to
distinguish between "virtualized nodes" and "bodily nodes" (anyone
having better name suggestions if welcome to propose them).
Other words, in the case like below is there any obvious way to see
that foo exists only virtually in the "DOM scripting cache" (again, a
better term is welcome), while bar is "fully existing"?

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<title>Test</title>
<script type="text/javascript">
var foo = null;
var bar = null;
window.onload = function() {
foo = document.getElementsByTagName('P')[0];
document.body.removeChild(foo);
window.setTimeout('test()',100);
}

function test() {
bar = document.getElementsByTagName('P')[0];
// foo and bar diffs as DOM objects?
}
</script>
</head>
<body>
<p>foo</p>
<p>bar</p>
</body>
</html>
 
V

VK

To OP:

IMHO adding/removing cover node is an overkill, it is enough to
display block/none. Also if you care for IE6 (based on the title of
your post you do), then you have to take care of the infamous "form
element super-z" bug (a.k.a. "form element firing through" bug).
Otherwise IE6 users will be able to freely interact with all form
elements, covered or not.

For inspirations and other caveats you may take a look at my
TransModal script. It is long time abandoned as I had to move on other
commercial projects, yet still...

http://groups.google.com/group/comp.lang.javascript/msg/c31d18013a2f99de
 
G

Gregor Kofler

VK meinte:
If the element has
an ID, try to fetch it with gEBI. Now *that* will return a null if
the element has been removed from the document.

How much do you bet on it? ;-)
[snip]
var p = null;
window.onload = function() {
p = document.getElementById('foo');
document.body.removeChild(p);
window.setTimeout('window.alert(p)',100);
// will show HTMLParagraphElement
// like never nothing

As expected. VK in all his glory - again.

Gregor
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,992
Messages
2,570,220
Members
46,805
Latest member
ClydeHeld1

Latest Threads

Top