The default bug view has changed. See this FAQ.

[FIX]If the initial text input value is longer than maxlength it is truncated.

RESOLVED FIXED in mozilla1.9alpha8

Status

()

Core
Layout: Form Controls
P1
normal
RESOLVED FIXED
11 years ago
9 years ago

People

(Reporter: mdew, Assigned: bz)

Tracking

({compat, testcase})

Trunk
mozilla1.9alpha8
compat, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

11 years ago
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
(Reporter)

Updated

11 years ago
Summary: Input maxlegth cuts off value → Input maxlength cuts off value

Comment 1

11 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.
(Reporter)

Comment 2

11 years ago
(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

11 years ago
Again, please provide an URL or attach a testcase that actually does
illustrate the error. Thanks.
(Reporter)

Comment 4

11 years ago
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.
I think this is a duplicate of bug 35230. Maybe the decision on bug 35230 should be reconsidered because of browser compatibility reasons?
(Reporter)

Comment 6

11 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

11 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

11 years ago
Component: Editor → Layout: Form Controls
QA Contact: layout.form-controls

Comment 7

11 years ago
Created attachment 230087 [details]
Testcase #1

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

11 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).
Yeah, compat is all good here, I think.  Hixie, want to spec this accordingly?
Flags: blocking1.9?
Keywords: compat
Duplicate of this bug: 277826
Blocks: 350786
Created attachment 276539 [details] [diff] [review]
Patch to that effect

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)
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

10 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 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+
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
Last Resolved: 10 years ago
Flags: blocking1.9? → in-testsuite?
Resolution: --- → FIXED

Comment 17

9 years ago
I'm still seeing this issue in FF 2.0.0.12, what release is this fixed in?
(Reporter)

Comment 18

9 years ago
it was fixed in firefox 3.0, not in 2.0
Depends on: 437379
Depends on: 444728
You need to log in before you can comment on or make changes to this bug.