Is there any plans for this? It's just bit me with the simpleModal plugin.

As far as I know it hasn't been reviewed yet. The discussion for it is http://groups.google.com/group/jquery-dev/browse_thread/thread/a7e315e586bd66b9/ff0edad983daa459?lnk=gst&q=ie+clone#ff0edad983daa459

Happened to me too, And then I thought, Why not cloning the first element instead the last?

The fix for the script (Not jQuery, but your example) is changing the row :

				$( '.test:last' ).clone( true );

To :

				$( '.test:first' ).clone( true );

>"Why not cloning the first element instead the last?"

Because the point isn't to find a workaround for the simplified test case, but rather to illustrate the existence of a bug.

Duplicate/related:

http://dev.jquery.com/ticket/2845

http://dev.jquery.com/ticket/3142

http://dev.jquery.com/ticket/3289

I have received this error for several clone circumstances. The underlying issue appears to be that the event re-attachment code for the cloned objects requires that the position of cloned elements be identical to the position of the original elements. (The event attachment code executes the each function on the original elements and references clone[i], where i is the position of the original element.)

I discovered that the clean function sometimes removes elements. In these cases, clone[i] is undefined where i >= clone.length but i < this.find("*").andSelf().length -- then undefined is passed to the jQuery.event.add function, and elem.nodeType in the add function throws the error.

To determine the number of dropped elements when you receive the error, insert the following line of code just after clone is initialized:

  var diff = this.find("*").andSelf().length - clone.length;

I have not been able to pinpoint the area of the clean function that is removing these elements; I am hoping that someone will take this line of thought with the provided example and discover the root cause.

Funny you should mention that, carmel_dev, I was looking at the clone() code and noticed that it depended on the node counts being identical as well. So I went looking for tickets that might be related to the two being out of sync.

Do you have some test cases that demonstrate the problem? I was thinking it might happen, for example, when adjacent text nodes are serialized into a string and then come back out as a single text node, but I couldn't reproduce a simple case.

See #3254 for more info.

Fixed in SVN rev [6186].