Bug 337498

Comment 1 Ian Trimble 2011-02-24 14:16:32 EST

Noticed during this week's smoke test: when dropped, the button renders as a button - as soon as the value attribute is changed, it renders as a textfield.

Comment 2 David Williams 2011-02-25 15:19:41 EST

Do you use XML/HTML DOM's do work with "inserting text"? I know Nitin et. al., have been fixing some stuff in DOM APIs lately ... so, adding him to CC, just in case.

Comment 3 Ian Trimble 2011-02-25 15:30:14 EST

We haven't had time to investigate yet, but we've released nothing in recent weeks, so the change is in a lower layer somewhere. Yes, we use DOM APIs.

Comment 4 Ian Trimble 2011-03-11 20:02:15 EST

Here are our findings.

On 2/22/11@5:25PM, Nitin submitted a change to ElementImpl.

In the method getAttributeNode(String), the following was added:

String implied = getDefaultValue(name, null);
if (implied != null) {
	Attr createdAttribute = getOwnerDocument().createAttribute(name);
	createdAttribute.setNodeValue(implied);
	return createdAttribute;
}

*Note that the created attribute is never appended to the Element's attribute list here.*

So when we pop out of this method and back to setAttribute(String, String), the newly-created attribute is not null and so the method returns before hitting subsequent code that used to append the attribute to the element when the attribute was null (which it now isn't whenever there is a "default implied attribute").

When there are no attributes at all on an element, getAttributeNode(String) returns null before it even attempts to create a default implied attribute, and so it works as it always used to in this case.

Reassigning (since it's a fault in ElementImpl) and bumping up severity (since not being able to use setAttribute(String, String) is a pretty serious limitation).

Comment 5 Nick Sandonato 2011-03-14 11:39:44 EDT

Created attachment 191130 [details]
patch with tests

Comment 6 Nick Sandonato 2011-03-16 16:03:11 EDT

Code checked into HEAD.