Community
Participate
Working Groups
In the Web Page Editor, drop a JSF HTML commandButton on the canvas, and it will render as a textfield. Inspect the "converted" HTML (e.g. from the source of the preview page) and notice that the type attribute is missing on the "converted" input element (and an input element without type defaults to being a textfield).
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.
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.
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.
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).
Created attachment 191130 [details] patch with tests
Code checked into HEAD.
