Closed
Bug 345267
Opened 18 years ago
Closed 17 years ago
[FIX]If the initial text input value is longer than maxlength it is truncated.
Categories
(Core :: Layout: Form Controls, defect, P1)
Core
Layout: Form Controls
Tracking
()
RESOLVED
FIXED
mozilla1.9alpha8
People
(Reporter: mp3geek, Assigned: bzbarsky)
References
()
Details
(Keywords: compat, testcase)
Attachments
(2 files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
MatsPalmgren_bugz
:
review+
MatsPalmgren_bugz
:
superreview+
dbaron
:
approval1.9+
|
Details | Diff | Splinter Review |
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
Comment 1•18 years ago
|
||
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.
Comment 3•18 years ago
|
||
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.
Comment 5•18 years ago
|
||
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.
Updated•18 years ago
|
Status: UNCONFIRMED → NEW
Component: General → Editor
Ever confirmed: true
Keywords: testcase
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
Updated•18 years ago
|
Component: Editor → Layout: Form Controls
QA Contact: layout.form-controls
Comment 7•18 years ago
|
||
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).
Comment 8•18 years ago
|
||
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).
Assignee | ||
Comment 9•18 years ago
|
||
Yeah, compat is all good here, I think. Hixie, want to spec this accordingly?
Assignee | ||
Comment 11•17 years ago
|
||
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.
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #276539 -
Flags: superreview?(mats.palmgren)
Attachment #276539 -
Flags: review?(mats.palmgren)
Assignee | ||
Updated•17 years ago
|
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
Reporter | ||
Comment 12•17 years ago
|
||
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 13•17 years ago
|
||
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)
Attachment #276539 -
Flags: superreview?(mats.palmgren)
Attachment #276539 -
Flags: superreview+
Attachment #276539 -
Flags: review?(mats.palmgren)
Attachment #276539 -
Flags: review+
Assignee | ||
Comment 14•17 years ago
|
||
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 15•17 years ago
|
||
Comment on attachment 276539 [details] [diff] [review]
Patch to that effect
a1.9=dbaron
Attachment #276539 -
Flags: approval1.9? → approval1.9+
Assignee | ||
Comment 16•17 years ago
|
||
Checked in, including those tests. Still need drag/drop and copy/paste tests, so marking in-testsuite?.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Flags: blocking1.9? → in-testsuite?
Resolution: --- → FIXED
Comment 17•17 years ago
|
||
I'm still seeing this issue in FF 2.0.0.12, what release is this fixed in?
Reporter | ||
Comment 18•17 years ago
|
||
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.
Description
•