1272029 - user selection not preserved on cloned HTML select elements

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[Boris Zbarsky [:bzbarsky]]

+++ This bug was initially created as a clone of Bug #230307 +++

Following the discussion in the DOM newsgroup thread
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=btfdbi%241dj1%40ripley.netscape.com&rnum=1&prev=/groups%3Fq%3Dgroup:*mozilla*dom*%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26scoring%3Dd
I file this bug. 
Mozilla when using the W3C DOM Core cloneNode method on HTML form controls
preserves the value property of text and password input controls but not of
textarea controls.
Similarly the checked property of radio and checkbox input controls is preserved
but not the selectedIndex property nor the value property of select controls,
nor the selected property of any contain option elements.
So the suggestion is to preserve the user input/selection on HTML form controls
consistently, meaning for textarea controls the value property is cloned and for
select elements the selectedIndex property and the value property is cloned as
well as the select property on any contained option element.


This bug covers the <select> part of that.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Per HTML spec, our behavior is correct as far as I can tell: there is no magic involved in cloning <select> in the spec; it just clones the DOM.

I just tested Blink, WebKit, and Edge, and none of them do any magic here either: a clone has the default option, if any, selected.  

Given that everyone agrees, and agrees with the spec, I don't think we should change behavior here.  Certainly not without coordinating with other UAs....

Comment 2

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, untouched DOM/Storage bug's priority.

If you have reason to believe, this is wrong, please write a comment and ni :jstutte.