The nice thing about DOM Inspector is that in this respect, for the time being, it shows exactly what exists in the DOM. So if there were a bug at play here, we would know with a high degree of confidence that a bug should be filed against Gecko itself. Programmatically poking at the element corroborates what's being shown; the attributes in the DOM Node viewer are the only attributes the element has. DOM Level 2 says: > When the type attribute of the element has the value "text", "file" or > "password", this represents the current contents of the corresponding form > control, in an interactive user agent. Changing this attribute changes the > contents of the form control, but does not change the value of the HTML > value attribute of the element. When the type attribute of the element has > the value "button", "hidden", "submit", "reset", "image", "checkbox" or > "radio", this represents the HTML value attribute of the element. <http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-49531485> HTML5 looks to be incomplete here, but it has something similar, with its "value" mode and "default" mode <http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#dom-input-value-value>, where "default" updates the value attribute and "value"... doesn't necessarily. When the input type is "hidden", the mode is "default"; when the input type is "text", the mode is "value" <http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#input-type-attr-summary>. (That table is non-normative, but I can't actually find the normative part of the spec that independently states anything resembling that mapping, so there you go.) Thanks for the bug report.