Closed Bug 345267 Opened 14 years ago Closed 13 years ago
[FIX]If the initial text input value is longer than maxlength it is truncated
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060718 Firefox/2.0b1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060718 Firefox/2.0b1 input value is cut off when maxlength= is shorter than the value. Value should still be displayed correctly regardless of maxlength Reproducible: Always Steps to Reproduce: 1. Visit site, input a large value in the input 2. Value is cut off by maxlength 3. Actual Results: Value is cut off by the size, rather than displayed. Expected Results: It should still display the value, and not cut off (correctly displayed by IE and Opera) It would be nice if this was fixed in time for Firefox 2.0
Summary: Input maxlegth cuts off value → Input maxlength cuts off value
Both the INPUTs in the example have: maxlength='255' size='50'. Please provide an URL or attach a HTML file (using the "Create a New Attachment" link on the bug report) that shows the problem.
(In reply to comment #1) > Both the INPUTs in the example have: maxlength='255' size='50'. > Please provide an URL or attach a HTML file (using the > "Create a New Attachment" link on the bug report) that shows the problem. > not really the point, since you won't be to input anything larger than maxlength. Its once you copy the data into the value, and *then* set the maxlength smaller than the data length, which will cut it off.
Again, please provide an URL or attach a testcase that actually does illustrate the error. Thanks.
Ok, a better description of the problem and simpler testcase.
Summary: Input maxlength cuts off value → If a value is larger than the maxlength, maxlength will crop it.
Well considering Opera and IE will still display the value, maxlength is being enforced when entering data sure, but just displaying data? what should happen (imo) if its a new box, with no value, adhere to maxvalue. if its a box with a existing value larger than maxlength, ignore maxlength and display value? I wont lose data because of this bug, just trying to make it uniform between IE and Opera.
Status: UNCONFIRMED → NEW
Component: General → Editor
Ever confirmed: true
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general
Hardware: PC → All
Summary: If a value is larger than the maxlength, maxlength will crop it. → If the initial text input value is longer than maxlength it is truncated.
Version: unspecified → Trunk
Component: Editor → Layout: Form Controls
QA Contact: layout.form-controls
When the initial value is longer than maxlength -or- Setting a value longer than maxlength with script: IE7 and Opera9: value is accepted as is Moz: truncates to maxlength (except if the new value is identical to the old, then no change) Setting maxlength < length of current value: IE7 and Opera9 and Moz: value does not change Deleting characters from the end of a value that is longer than maxlength: IE7 and Opera9 and Moz: only one character is deleted (even if the new value is still longer than maxlength) Pasting over part of the value, for example: set the value to 123456, set the maxlength to 2. Copy a two character string to the clipboard and then select "56" in the text input and Paste. IE7 and Moz: removes the selected part (56) but does not insert new text above maxlength, the value becomes 1234. (for Moz: even Pasting 56 so that the value becomes the same removes the text, so there is no "same value" exception here like in the first test above). Opera9: does not change the value at all Undo (CTRL+Z) to an old value that is longer than maxlength: IE7: typing one CTRL+Z does not change the value. typing one more CTRL+Z does not change the value. (and so forth) Holding down CTRL+Z so that it repeats brings back the old value. weird. Opera9: first CTRL+Z truncates the value to the empty string (weird), second CTRL+Z restores the old value (no truncation even though it's longer than maxlength) Moz: first CTRL+Z restores the old value (no truncation even though it's longer than maxlength) IE7 = IE7beta2 on Windows XPSP2 Opera9 = Opera 9.0 on Windows XPSP2 Moz = SeaMonkey recent trunk on Windows XPSP2 (and same results on Linux).
My 2 cents: I agree this is a compatibility bug and that we should accept initial and acript assigned values that are longer than maxlength, those values comes from the page/script author after all. For user edit operations we should keep our current behaviour. This change would makes us compatible with IE7/Opera9 (except for some Undo edge cases where I think our current behaviour is ok as is).
Yeah, compat is all good here, I think. Hixie, want to spec this accordingly?
This includes all the tests mentioned in the bug except the paste test... I can't figure out how to test that offhand without clobbering my clipboard, and that makes me pretty unhappy. If someone would be willing to step up and do it, that would rock.
Priority: -- → P1
Summary: If the initial text input value is longer than maxlength it is truncated. → [FIX]If the initial text input value is longer than maxlength it is truncated.
Target Milestone: --- → mozilla1.9 M8
Tested the patch with our site, and the works nicely with the testcase. I originally submitted this bug due to the fact our internal customer billing site was designed around IE. Annoyed me that any user names larger than a certain value don't show correctly because of the mozilla max length bug. No data is loss because of this bug, more a compatibility issue than anything. but it would be nice to get this fix into 3.0 :)
Comment on attachment 276539 [details] [diff] [review] Patch to that effect Looks good. r+sr=mats (I also tested copy/paste/drag-n-drop etc)
Comment on attachment 276539 [details] [diff] [review] Patch to that effect This is a fairly safe patch that gives us compat with other UAs in the handling of maxlength when scripted sets or default values exceed it. Code risk is zero, web compat risk is low because we now match behavior of other UAs.
Attachment #276539 - Flags: approval1.9?
Comment on attachment 276539 [details] [diff] [review] Patch to that effect a1.9=dbaron
Attachment #276539 - Flags: approval1.9? → approval1.9+
Checked in, including those tests. Still need drag/drop and copy/paste tests, so marking in-testsuite?.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Flags: blocking1.9? → in-testsuite?
Resolution: --- → FIXED
I'm still seeing this issue in FF 18.104.22.168, what release is this fixed in?
it was fixed in firefox 3.0, not in 2.0
You need to log in before you can comment on or make changes to this bug.