Cloning elements with shadow DOM does redundant element creation

• Component: DOM
• Status: RESOLVED INVALID

[Dominic Cooney]

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.

[Kent Tamura]

So, reverting http://trac.webkit.org/changeset/84528/trunk/Source/WebCore/dom/Element.cpp will solve everything?

[Kent Tamura]

I meant reverting http://trac.webkit.org/changeset/84528 .

[Dominic Cooney]

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.

[Kent Tamura]

(In reply to comment #3)
Keygen build the shadow tree in the constructor.   Cloning a keygen needs nothing else, right?

[Dominic Cooney]

Yes, you’re right, keygen would work if r84528 was reverted. Maybe we should revert it…

[Hajime Morrita]

Is this valid yet?

[Dominic Cooney]

Since r84528 was reverted, this bug is no longer applicable.