Last Comment Bug 345267 - [FIX]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.
Status: RESOLVED FIXED
: compat, testcase
Product: Core
Classification: Components
Component: Layout: Form Controls (show other bugs)
: Trunk
: All All
: P1 normal (vote)
: mozilla1.9alpha8
Assigned To: Boris Zbarsky [:bz] (still a bit busy)
:
:
Mentors:
http://www.fanboy.co.nz/new2.html
: 277826 (view as bug list)
Depends on: 437379 444728
Blocks: 350786
  Show dependency treegraph
 
Reported: 2006-07-19 18:15 PDT by mdew
Modified: 2008-07-12 19:12 PDT (History)
11 users (show)
bzbarsky: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Testcase #1 (1.10 KB, text/html)
2006-07-20 23:14 PDT, Mats Palmgren (:mats)
no flags Details
Patch to that effect (11.55 KB, patch)
2007-08-13 14:43 PDT, Boris Zbarsky [:bz] (still a bit busy)
mats: review+
mats: superreview+
dbaron: approval1.9+
Details | Diff | Splinter Review

Description mdew 2006-07-19 18:15:42 PDT
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
Comment 1 Mats Palmgren (:mats) 2006-07-19 20:57:33 PDT
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.
Comment 2 mdew 2006-07-19 21:08:13 PDT
(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 Mats Palmgren (:mats) 2006-07-19 21:46:52 PDT
Again, please provide an URL or attach a testcase that actually does
illustrate the error. Thanks.
Comment 4 mdew 2006-07-19 22:28:24 PDT
Ok, a better description of the problem and simpler testcase. 
Comment 5 Martijn Wargers [:mwargers] (not working for Mozilla) 2006-07-20 05:18:13 PDT
I think this is a duplicate of bug 35230. Maybe the decision on bug 35230 should be reconsidered because of browser compatibility reasons?
Comment 6 mdew 2006-07-20 06:19:36 PDT
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.
Comment 7 Mats Palmgren (:mats) 2006-07-20 23:14:57 PDT
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 Mats Palmgren (:mats) 2006-07-20 23:24:29 PDT
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).
Comment 9 Boris Zbarsky [:bz] (still a bit busy) 2006-07-21 12:49:50 PDT
Yeah, compat is all good here, I think.  Hixie, want to spec this accordingly?
Comment 10 Boris Zbarsky [:bz] (still a bit busy) 2007-08-13 10:02:06 PDT
*** Bug 277826 has been marked as a duplicate of this bug. ***
Comment 11 Boris Zbarsky [:bz] (still a bit busy) 2007-08-13 14:43:28 PDT
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.
Comment 12 mdew 2007-08-14 03:30:44 PDT
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 Mats Palmgren (:mats) 2007-08-21 10:48:54 PDT
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 14 Boris Zbarsky [:bz] (still a bit busy) 2007-08-21 12:03:41 PDT
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.
Comment 15 David Baron :dbaron: ⌚️UTC-7 2007-08-21 17:21:05 PDT
Comment on attachment 276539 [details] [diff] [review]
Patch to that effect

a1.9=dbaron
Comment 16 Boris Zbarsky [:bz] (still a bit busy) 2007-08-21 20:22:53 PDT
Checked in, including those tests.  Still need drag/drop and copy/paste tests, so marking in-testsuite?.
Comment 17 Marky 2008-03-03 17:12:44 PST
I'm still seeing this issue in FF 2.0.0.12, what release is this fixed in?
Comment 18 mdew 2008-03-03 17:17:56 PST
it was fixed in firefox 3.0, not in 2.0

Note You need to log in before you can comment on or make changes to this bug.