Testcase: data:text/html,<script>var i = document.createElement("input"); i.setAttribute("size", "foo 42 bar"); alert("attr: '" + i.size + "'");</script> It should show "20", input.size default value. Instead, we show "42". Presto and Webkit show "0" but that's because they believe '0' is input.size default value. Very likely, the reasons of this bug are close to bug 679671.

Right now we skip any leading non-numbers in nsAttrValue::StringToInteger. What does the spec say to do for various integer-valued attributes instead?

(In reply to Boris Zbarsky (:bz) from comment #1) > Right now we skip any leading non-numbers in nsAttrValue::StringToInteger. > What does the spec say to do for various integer-valued attributes instead? We should skip any leading non-numbers. That is what the specs require and other browsers do but that is not what we are doing. The code in nsAttrValue::StringToInteger seems to do that but ends up calling nsAutoString::ToInteger(). I would guess this method consider "foo 42 bar" to be the integer 42. Actually, generally speaking, it's not really clear why we are calling nsAutoString::ToInteger() when the algorithm isn't able to find an integer. It seems to be a good way to not follow the specs. FWIW, I think what the specs ask is close to what parseInt() does.

Uh, no. The spec want us to skip whitespace, not just any random junk. All random junk *at the end*, otoh, is ignored.

I don't know if you were replying to me or Boris but indeed leading whitespaces are ignored, it was without saying.

So yes, sounds like we should change StringToInteger to bail out on finding non-whitespace non-numbers instead of pressing on.

I assume this will be fixed by bug 673820.