Bug 28001 - <input> should not trim initial value to maxLength
Summary: <input> should not trim initial value to maxLength
Status: RESOLVED DUPLICATE of bug 21271
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Michelangelo De Simone
URL: http://software.hixie.ch/utilities/js...
Keywords:
Depends on:
Blocks: 27454
  Show dependency treegraph
 
Reported: 2009-08-04 15:16 PDT by Peter Kasting
Modified: 2009-08-25 09:55 PDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Kasting 2009-08-04 15:16:53 PDT
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.
Comment 1 Peter Kasting 2009-08-04 15:22:30 PDT
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".
Comment 2 Michelangelo De Simone 2009-08-04 18:44:36 PDT
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)?
Comment 3 Peter Kasting 2009-08-04 22:43:15 PDT
(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.
Comment 4 Peter Kasting 2009-08-25 09:55:04 PDT

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