Iron label seems to create two values in the serialization.

[ianjosephwilson]

Description

The iron-form element serializes two values in an array when wrapped an input with iron-label.

Expected outcome

Only 1 String value should be in the serialization for the input's name.

Actual outcome

An array of 2 Strings is in the serialization for the input's name.

Live Demo

https://jsbin.com/kohumos/edit?html,output

Steps to reproduce

1. Wrap the iron-label around text and an input.
2. Wrap that in a form and that in an iron-form.
3. Call serializeForm on ironForm.
4. Two values will be under the input's name in the serialization.

Browsers Affected

• [x] Chrome
• [ ] Firefox
• [ ] Safari 9
• [ ] Safari 8
• [ ] Safari 7
• [ ] Edge
• [ ] IE 11
• [ ] IE 10

[TomK]

Maybe related #205

[ianjosephwilson]

I think the check for more elements should be on shadowRoot on this line:

Array.prototype.push.apply(submittable, this._findElements(node.root, ignoreName));

https://github.com/PolymerElements/iron-form/blob/master/iron-form.html#L373

The root element appears to be both either the light dom or the shadow root. The iron-labels have this property so when I wrap an input it gets loaded twice, I think it is in the light dom in iron-label, so it is a child of the form element and then picked up again as the child of the label element, creating double entries in values.

Here you can see the root property in polymer source is doc'ed as HTMLElement or ShadowRoot.

https://github.com/Polymer/polymer/blob/master/lib/mixins/element-mixin.html#L557

/** @type {StampedTemplate | HTMLElement | ShadowRoot} */
        this.root;

I'm not experienced enough with polymer to know what to do here. Is changing root to shadowRoot an adequate change here?

[TomK]

I don't think it should be traversing shadow at all. There is some brief discussion in the other issue about this, but I think it could do with more input.

[ianjosephwilson]

Thinking more about it... if or if not the shadowdom should be traversed I think is out of the scope of this issue other than changing that line to find any inputs that wouldn't be found otherwise. The original intention was to just get any inputs not collected already not to collect them twice I think this is just a bug.