Response title
This is preview!
Two strangeness in domManip
in Developing jQuery Core
•
11 years ago
jQuery.support.parentNode disappeared between 1.4.2 and 1.5.1.
It is used in domManip to check (in a very suspicious way) if a fragment can be reused.
Since jQuery.support.parentNode is not defined any more, that "optimization" is never applied.
Instead of removing the jQuery.support.parentNode part to re-enabling the optimization, I suggest to remove it entirely because it would unlikely happen anyway, and could wrongly reuse an existent fragment that contains not only the interested elements.
The other thing that I spotted is about code introduced by this commit.
Removing that code, I was unabled to reproduce the bug because I have not an sufficiently old WebKit browser.
However, even without reproducing it, it is obvious that the check (and respective unit tests) considers only the first argument, and only if it is a string, ignoring the fact that a fragment could also be generated (and than cloned) by rest of arguments, and that those arguments can also be existent nodes.
Also, the fix ignores the fact that jQuery.clone already handles similar problems, so to resolve this I suggest to remove any usage of support.checkClone and to combine it with support.noCloneChecked. In this way jQuery.clone would be able to automatically handle the problem via cloneFixAttributes.
For both problems I am willing to open tickets with respective patches.
BTW. doing this, we wold gain some extra bytes.
It is used in domManip to check (in a very suspicious way) if a fragment can be reused.
Since jQuery.support.parentNode is not defined any more, that "optimization" is never applied.
Instead of removing the jQuery.support.parentNode part to re-enabling the optimization, I suggest to remove it entirely because it would unlikely happen anyway, and could wrongly reuse an existent fragment that contains not only the interested elements.
The other thing that I spotted is about code introduced by this commit.
Removing that code, I was unabled to reproduce the bug because I have not an sufficiently old WebKit browser.
However, even without reproducing it, it is obvious that the check (and respective unit tests) considers only the first argument, and only if it is a string, ignoring the fact that a fragment could also be generated (and than cloned) by rest of arguments, and that those arguments can also be existent nodes.
Also, the fix ignores the fact that jQuery.clone already handles similar problems, so to resolve this I suggest to remove any usage of support.checkClone and to combine it with support.noCloneChecked. In this way jQuery.clone would be able to automatically handle the problem via cloneFixAttributes.
For both problems I am willing to open tickets with respective patches.
BTW. doing this, we wold gain some extra bytes.
1