<input> should not trim initial value to maxLength

• Component: Forms
• Status: RESOLVED DUPLICATE

[Peter Kasting]

In WebKit, <input value=foobar maxLength=3> displays a textfield containing "foo".  In Firefox, IE, and Opera, it displays "foobar".  We should match this.  (Testcase at the URL above.)

This probably also applies to values set by scripting the DOM.

When the value is longer than maxLength, and the user attempts to modify the value in place, IE and Firefox apply the following algorithm:
* Delete the selected character(s)
* If the value is now shorter than maxLength, insert characters from the user's attempted insertion value, stopping when the length of the element's value equals maxLength.

Opera is stranger; its first step is:
* If deleting the selected character(s) will not make the resulting value shorter than maxLength, abort without doing anything; otherwise, delete the selected character(s) and proceed.

As a result, when the element contains "foobar" with maxLength 3, and the clipboard contains "zyx":
* On IE and Firefox, selecting "r" and typing a key or pasting will delete "r".  On Opera, this will do nothing.
* On IE and Firefox, selecting "foo" and typing a key or pasting will delete "foo".  On Opera, this will do nothing.
* On all three browsers, selecting "ooba" and pasting will result in "fzr".

I think the IE and Firefox behavior, while at first stranger, is more consistent.

[Peter Kasting]

Note: WebKit already does the second step above, where it pastes in as much as will fit.  To see this, visit the example URL, select one character of "foo", and try pasting "maxLength".  You'll see the selected character replaced by "m".

[Michelangelo De Simone]

Peter, do you think that we should get the standard maxlength interface in this patch, as well as adjusting the "0" issue (0 is not an accepted value now)?

[Peter Kasting]

(In reply to comment #2)
> Peter, do you think that we should get the standard maxlength interface in this
> patch, as well as adjusting the "0" issue (0 is not an accepted value now)?

"standard maxlength interface"?  Do you mean unsigned long versus long?  If so, then no, I don't think we should do that on this bug.  I think this bug should stick to what I filed it as being about, and other maxLength changes can go on bug 27454 or on new bugs that block that bug.

[Peter Kasting]

*** This bug has been marked as a duplicate of bug 21271 ***