Bug Tracker

Opened 12 years ago

Closed 12 years ago

#9172 closed bug (wontfix)

Setting the value attribute for the first time in IE6/7 sets the value property

Reported by: timmywil Owned by:
Priority: low Milestone: 1.next
Component: attributes Version: 1.6
Keywords: Cc:
Blocked by: Blocking:

Description (last modified by timmywil)

For .attr("value", "something").

This is an edge case, but I'm not sure how to fix it. Normally, we do

.getAttributeNode("value").nodeValue = "something";

This will leave the value property unaffected. However, if the content attribute does not yet exist on the element (i.e. getAttributeNode returns null), the property is set in IE6/7 when the fallback setAttribute("value", "something") is called. This is usually ok since most elements would have their value set along with defaultValue, but it is a problem with textareas where there can be a value already set that should override the defaultValue( I think ).


Change History (5)

comment:1 Changed 12 years ago by timmywil

Component: unfiledattributes
Priority: undecidedlow
Status: newopen

comment:2 Changed 12 years ago by timmywil

Description: modified (diff)

comment:3 Changed 12 years ago by [email protected]

I think I've got something similar to this in IE9.

var $node = $('<input type="text" value="44" />').appendTo(parentElem); $node.val(xmlNode.textContent);

where xmlNode is an XML attribute, and textContent = "5000" I check before the val call, and value is set to 44, after the val call value is set to 5000, but 44 appears in the browser.

comment:4 in reply to:  3 Changed 12 years ago by [email protected]

Replying to [email protected]:

I think I've got something similar to this in IE9.

Never mind. I had a parentElem.innerHTML += statement later in the code which was triggering the dom fragments to be recreated.

comment:5 Changed 12 years ago by timmywil

Resolution: wontfix
Status: openclosed

We're falling back to prop for value for back compat.

Note: See TracTickets for help on using tickets.