cloneNode and iterating event listeners

[Csaba Gabor]

One of the things that I never understood was the motivation for not
being able to iterate over the event listeners added via
..addEventListe ner It's particularly vexing because if you do
element.cloneNo de(bDeep), you frequently get a stunted clone, often
with several key features missing, and one of these is associated event
handlers. Of course, it could be the case that the event handlers have
a closure including a reference to the original node, but still...

So I rewrote addEventListene r, and removeEventList ener so that
cloneNode could be accomodated. The below is a framework, and needs
some work, (including the transfer of attributes).

Csaba Gabor from Vienna

How it works. When you enter a character, you get a message box.
This is what lets you verify that the cloning of event handlers
worked. Before cloning, make a selection to see that the selection
is transferred, too.

<form action="" method=get>
<textarea id=foo name=foo style="color:re d">This is some
starter text in a textarea</textarea>
<button type=button onclick="replac eWithClone(elem ('foo'))"
accesskey=c><u> C</u>lone</button>
</form>

<script type='text/javascript'>
function elem(id) { return document.getEle mentById(id); }
fixCloneNode(el em('foo'));
elem('foo').add EventListener(" input",
function() { alert("New text: " + this.value); }, false);

function fixCloneNode(el em) {
var oldAEL = elem.addEventLi stener;
var aListeners = [];
elem.addEventLi stener =
function (oldAEL, aListeners) {
return function (evt, func, bCapture) {
oldAEL.call (this, evt, func, bCapture)
aListeners.push ( [evt, func, bCapture] ); } }
(oldAEL, aListeners);

var oldREL = elem.addEventLi stener;
elem.removeEven tListener =
function (oldREL, aListeners) {
return function (evt, func, bCapture) {
for (var i=aListeners.le ngth;--i;)
if (aListeners[i][0]==evt && aListeners[i][1]==func &&
aListeners[i][2]==bCapture)
aListeners.spli ce(i,1);
} } (oldREL, aListeners);

var oldClone = elem.cloneNode;
elem.cloneNode =
function (oldAEL, aListeners, oldClone) {
return function (bDeep) {
// does not reproduce the event listeners
var elem = oldClone.call (this, bDeep);
elem.addEventLi stener = this.addEventLi stener;
elem.removeEven tListener = this.removeEven tListener;
elem.cloneNode = this.cloneNode;
if (elem.nodeName= ="TEXTAREA") elem.value = this.value;
for (var i=0;i<aListener s.length;++i) {
var aList=aListener s[i];
this.removeEven tListener(aList[0], aList[1], aList[2]);
oldAEL.call (elem, aList[0], aList[1], aList[2]); }
return elem; } } (oldAEL, aListeners, oldClone);
}

function replaceWithClon e(ta) {
var newTa = ta.cloneNode(tr ue);
var start = ta.selectionSta rt, end=ta.selectio nEnd;
ta.parentNode.r eplaceChild(new Ta, ta);
// Doesn't work properly with reverse selections
newTa.setSelect ionRange (start, end);
}
</script>

[Thomas 'PointedEars' Lahn]

Csaba Gabor wrote:

One of the things that I never understood was the motivation for not
being able to iterate over the event listeners added via
.addEventListen er It's particularly vexing because if you do
element.cloneNo de(bDeep), you frequently get a stunted clone, often
with several key features missing, and one of these is associated event
handlers. Of course, it could be the case that the event handlers have
a closure including a reference to the original node, but still...

So I rewrote addEventListene r, and removeEventList ener so that
cloneNode could be accomodated. The below is a framework, and needs
some work, (including the transfer of attributes).
[...]
How it works. [...]

For appropriate values of "works". It has been pointed out many times
that it is error-prone to assume that you can add or modify properties
of host objects arbitrarily. You do it anyway.
PointedEars
--
When you have eliminated all which is impossible, then
whatever remains, however improbable, must be the truth.
-- Sherlock Holmes

[Csaba Gabor]

Another PointedEars INC post.

Thomas 'PointedEars' Lahn wrote:

Csaba Gabor wrote:

One of the things that I never understood was the motivation for not
being able to iterate over the event listeners added via
.addEventListen er It's particularly vexing because if you do
element.cloneNo de(bDeep), you frequently get a stunted clone, often
with several key features missing, and one of these is associated event
handlers. Of course, it could be the case that the event handlers have
a closure including a reference to the original node, but still...

So I rewrote addEventListene r, and removeEventList ener so that
cloneNode could be accomodated. The below is a framework, and needs
some work, (including the transfer of attributes).
[...]
How it works. [...]
For appropriate values of "works".

Whatever
It has been pointed out many times
And you don't even back it up with a single reference? For shame.
that it is error-prone to assume
Assuming things is error prone in general.
that you can add or modify properties of host objects arbitrarily.
And this affects me how? Rather than making unsubstantiated and/or
irrelevant claims, it would be preferable to have either a concrete
counterexample or offer a method to improve upon, or at least
complement the subject matter of the post.
You do it anyway.

You do neither.