61997 2011-06-03 00:53:42 -0700 Cloning elements with shadow DOM does redundant element creation 2011-06-06 21:51:34 -0700 1 1 1 Unclassified WebKit DOM 528+ (Nightly build) Unspecified Unspecified RESOLVED INVALID P2 Normal --- 61983 1 dominicc webkit-unassigned morrita tkent oldest_to_newest 414703 0 dominicc 2011-06-03 00:53:42 -0700 Cloning an element with shadow DOM typically does redundant element creation. For example, cloning an <input type="range" style="…"> creates one shadow slider element during the HTMLInputElement clone when it clones its type attribute (which creates a RangeInputType, which creates a shadow subtree for the slider.) Then Element::copyNonAttributeProperties destroys that shadow subtree and creates another shadow subtree that is a clone of the shadow subtree of the original node. We only need one of these two shadow trees. 414759 1 tkent 2011-06-03 03:32:28 -0700 So, reverting http://trac.webkit.org/changeset/84528/trunk/Source/WebCore/dom/Element.cpp will solve everything? 414760 2 tkent 2011-06-03 03:33:08 -0700 I meant reverting http://trac.webkit.org/changeset/84528 . 414762 3 dominicc 2011-06-03 03:42:16 -0700 Reverting 84528 will ensure that there is no redundant element creation. However it does not ensure that cloned elements end up with valid shadow trees. (For example, <keygen> has no hook to clone its shadow.) I think we need a general solution where elements with shadow roots get notified when they are cloned, so that they can participate in the clone. For elements like <input type="…"> where setting the type attribute will create a shadow tree anyway, it can just assert that the shadow tree was created. For elements like keygen, it can create the clone shadow tree at that point. 414763 4 tkent 2011-06-03 03:53:44 -0700 (In reply to comment #3) Keygen build the shadow tree in the constructor. Cloning a keygen needs nothing else, right? 414767 5 dominicc 2011-06-03 04:03:19 -0700 Yes, you’re right, keygen would work if r84528 was reverted. Maybe we should revert it… 416295 6 morrita 2011-06-06 21:36:36 -0700 Is this valid yet? 416308 7 dominicc 2011-06-06 21:51:34 -0700 Since r84528 was reverted, this bug is no longer applicable.