The page http://cws.internet.com/new.html contains an input with a SIZE attribute value of "10,1". This is interpreted as 10 in Nav 4.x. In Gecko, our attempt to convert the string into an integer (in nsString::ToInteger()) fails and we get a size of 0.

Rick, the size attribute "10,1" is parsed during AddAttributes (I'll attach a stack trace). When in ToInteger (no radix), it is sent to GetNumericSubstring, which returns "1". The number is from there converted into the integer value 1. For backwards compatibility could GetNumbericSubstring on "10,1" return "10", or would this cause problems elsewhere?

You should really break your string up into parts. I chose an algorithm for ToInteger() that is backward compatible. It allows a little bit of sloppiness, but your request begins to border on "knowing too much".

If what you're mean by "You should..." is that the web author should break up his strings, I understand and agree. This is, however, a case where the stringToInteger code is not backwards compatible with either Nav 4.x or IE 5.0 Unfortunately, the form frame code can not break up the web author's string to make this specific case backwards compatible. The frame code does not have access to the string as it is converted to an integer during document parsing (AddAttributes), before the frame is even created.

After some thinking, I agree with Rick. This is a case where the spec is not defined. It merely says: ... HTML 4.0 Section 17.4... size = cdata [CN] This attribute tells the user agent the initial width of the control. The width is given in pixels except when type attribute has the value "text" or "password". In that case, its value refers to the (integer) number of characters. ... Taking the last number in a malformed, comma-delimited list is just as reasonable an action as taking the first. I'm marking this bug VERIFIED.

*** Bug 5039 has been marked as a duplicate of this bug. ***