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
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.
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.
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).
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?
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.
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.
Comment on attachment 276539 [details] [diff] [review] Patch to that effect a1.9=dbaron
Checked in, including those tests. Still need drag/drop and copy/paste tests, so marking in-testsuite?.
I'm still seeing this issue in FF 22.214.171.124, what release is this fixed in?
it was fixed in firefox 3.0, not in 2.0