Bug 29796 – .maxLength should return -1 if maxlength attribute is not specified

• Component: Forms
• Status: RESOLVED FIXED

[Kent Tamura]

HTML5 draft was updated so that .maxLength IDL attributes are signed, and shoud return -1 if the corresponding HTML attribute is missing.

[Kent Tamura]

In Firefox 3.5 and Opera 10, input.maxLength returns -1 in that case.  In IE8, input.maxLength returns 2147483647.  They don't support for textarea.maxLength yet.

In WebKit, input.maxLength returns 524288 for now.

[Kent Tamura]

HTML5 draft says:
> If, on the other hand, it fails or returns an out of range value, or if the attribute
> is absent, the default value must be returned instead, or −1 if there is no default
> value. On setting, if the value is negative, the user agent must fire an
> INDEX_SIZE_ERR exception. Otherwise, the given value must be converted to the
> shortest possible string representing the number as a valid non-negative integer
> and then that string must be used as the new content attribute value.

We may return "the default value".  So it's ok that HTMLInputElement.maxLength returns 524288 in WebKit, 2147483647 in IE8.

[Kent Tamura]

Created attachment 40283 [details]
Proposed patch

The patch addresses
 - HTMLTextAreaElement.maxLength value without maxlength= attribute
 - INDEX_SIZE_ERR

[Darin Adler]

Comment on attachment 40283 [details]
Proposed patch

> -void HTMLInputElement::setMaxLength(int _maxLength)
> +void HTMLInputElement::setMaxLength(int _maxLength, ExceptionCode& exceptionCode)
>  {
> -    setAttribute(maxlengthAttr, String::number(_maxLength));
> +    if (_maxLength < 0)
> +        exceptionCode = INDEX_SIZE_ERR;
> +    else
> +        setAttribute(maxlengthAttr, String::number(_maxLength));
>  }

Underscore in the argument name is usually something we'd want to avoid. One of the few abbreviations we use consistently in WebCore code is "ec" for the exception code. I think using exceptionCode instead is nicer, but I'd prefer to stay consistent.

I was under the impression that INDEX_SIZE_ERR was usually generated by having an attribute of type unsigned long in IDL and handled automatically by the bindings. Could you find another example and make sure you are doing this consistently?

r=me as-is, but please consider the comments above too.

[WebKit Commit Bot]

Comment on attachment 40283 [details]
Proposed patch

Clearing flags on attachment: 40283

Committed r48903: <http://trac.webkit.org/changeset/48903>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Kent Tamura]

(In reply to comment #4)
> (From update of attachment 40283 [details])
> > -void HTMLInputElement::setMaxLength(int _maxLength)
> > +void HTMLInputElement::setMaxLength(int _maxLength, ExceptionCode& exceptionCode)
> >  {
> > -    setAttribute(maxlengthAttr, String::number(_maxLength));
> > +    if (_maxLength < 0)
> > +        exceptionCode = INDEX_SIZE_ERR;
> > +    else
> > +        setAttribute(maxlengthAttr, String::number(_maxLength));
> >  }

> I was under the impression that INDEX_SIZE_ERR was usually generated by having
> an attribute of type unsigned long in IDL and handled automatically by the
> bindings. Could you find another example and make sure you are doing this
> consistently?

For example, HTMLTableElement::insertRow(long) and deleteRow(long)  have similar code.  I couldn't find examples of properties, not functions.
We need to use signed long for maxLength IDL definition because it can return -1.  I think we have no choices other than this code.