Build ID: 2000040815 See attached testcase for bug description.
This will be either an "HTML Form Controls" bug or an "Editor" bug; trying the former.
While ie5 and nav4x have the same behaviour on win32, and the nav4x behaviour is consistent across mac-linux-win32 platforms, I note two caveats: 1) ie5.5 on the mac -- this immediately truncates the input value to two characters "th" and tosses the rest of the initial value. So there is no standard behaviour for IE 5.x 2) I can't think of a use case where you want a field with (maxlength < size). Using the testcase attachment is counter-intuitive (and would be very confusing if you didn't know what to expect beforehand).
you bring up a good point; i was unaware that IE 5.x textbox behavior varied between Mac and Win32. Still, I believe Mozilla's current behavior to be confusing, despite how rarely a situation such as this might come up. Displaying all of the text in the box and then trimming it to maxlength when the user initially sets focus to it is just confusing and strange behavior; I think it should either trunctate on page load a la IE 5.x on the mac, or use the behavior of NS 4.x and IE 5.x on Windows (see attached testcase for a description of this behavior). Also, I recognize your point that there's not too many useful applications for having maxlength < size, but still, it could easily happen and thus I don't think we should dismiss it based on rarity. The only semi-useful yet still confusing application of it that I can think of is to have a textbox with an initial value of, for example, "Type Two Letter State Code Here" and then a maxlength of 2. On second thought, in the above example, trunctating to two characters after focus would make it easier for the user as they wouldn't have to erase that entire msg just to type their two-letter state code. It's a sticky issue, rods what do you think?
in the current build on win32, when the textfield gets focus, the characters outside of the maxlength get truncated, which is fine. The user is unable to enter more text than the maxlength value, which is correct. The behavior is correct. The initial value is displayed correctly and IMHO seems logical to have it truncated to the allowable # of characters when it gets focus. Marking this as a won't fix.
agreed. verif. wfm
*** Bug 38532 has been marked as a duplicate of this bug. ***
*** Bug 244967 has been marked as a duplicate of this bug. ***
*** Bug 329097 has been marked as a duplicate of this bug. ***
Here's a use case that our company is running into: - Suppose maxlength is 10. - User enters value "1234567890", the user then saves the value (presumably this is stored in a database). - Administrator sets the maxlength of the field to 5. - User, in passing, edits the page again, exposing the field which will now display "12345". The user does not know the value that is stored in this field. - Now user makes other changes to the page and presses save. The field is saved and unwillingly, the user has truncated the field. In essence, the browser has went ahead and assumed that the last 5 characters were the ones to remove. Given this scenario using IE, the user is displayed the entire field to edit, the user can choose how to reduce the size. If the field is too long, perhaps the page can be redisplayed with an error message or whatever. The browser makes no assumptions of how to correct the problem, and there is a clear distinction between the initial supplied value of the field (the "value" attribute) and the restriction imposed on user supplied values for the field (the "maxlength" attribute). Please reevaluate this defect, with this use case in mind. A "WONTFIX" is not an appropriate resolution. Thank you for a wonderful browser, however, which I am overjoyed to use.