Text from value attribute cut to maxlength on textbox focus

VERIFIED WONTFIX

Status

()

Core
Layout: Form Controls
P3
normal
VERIFIED WONTFIX
18 years ago
12 years ago

People

(Reporter: Blake Ross, Assigned: rubydoo123)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
Build ID: 2000040815

See attached testcase for bug description.
(Reporter)

Comment 1

18 years ago
Created attachment 7384 [details]
testcase

Comment 2

18 years ago
This will be either an "HTML Form Controls" bug or an "Editor" bug;
trying the former.
Assignee: trudelle → rods
Component: XP Toolkit/Widgets → HTML Form Controls
Keywords: 4xp
QA Contact: jrgm → ckritzer
Summary: Text from value attribute is cut to maxlength on textbox focus → Text from value attribute cut to maxlength on textbox focus

Comment 3

18 years ago
While ie5 and nav4x have the same behaviour on win32, and the nav4x behaviour 
is consistent across mac-linux-win32 platforms, I note two caveats:

1) ie5.5 on the mac -- this immediately truncates the input value to two       
characters "th" and tosses the rest of the initial value. So there is no
   standard behaviour for IE 5.x

2) I can't think of a use case where you want a field with (maxlength < size).
   Using the testcase attachment is counter-intuitive (and would be very       
   confusing if you didn't know what to expect beforehand).
(Reporter)

Comment 4

18 years ago
you bring up a good point; i was unaware that IE 5.x textbox behavior varied 
between Mac and Win32.  Still, I believe Mozilla's current behavior to be 
confusing, despite how rarely a situation such as this might come up.  
Displaying all of the text in the box and then trimming it to maxlength when the 
user initially sets focus to it is just confusing and strange behavior; I think 
it should either trunctate on page load a la IE 5.x on the mac, or use the 
behavior of NS 4.x and IE 5.x on Windows (see attached testcase for a 
description of this behavior).

Also, I recognize your point that there's not too many useful applications for 
having maxlength < size, but still, it could easily happen and thus I don't 
think we should dismiss it based on rarity.   The only semi-useful yet still 
confusing application of it that I can think of is to have a textbox with an 
initial value of, for example, "Type Two Letter State Code Here" and then a 
maxlength of 2.

On second thought, in the above example, trunctating to two characters after 
focus would make it easier for the user as they wouldn't have to erase that 
entire msg just to type their two-letter state code.

It's a sticky issue, rods what do you think?

Comment 5

18 years ago
reassigning
Assignee: rods → beppe
(Assignee)

Comment 6

18 years ago
in the current build on win32, when the textfield gets focus, the characters 
outside of the maxlength get truncated, which is fine. The user is unable to 
enter more text than the maxlength value, which is correct. The behavior is 
correct. The initial value is displayed correctly and IMHO seems logical to have 
it truncated to the allowable # of characters when it gets focus. Marking this 
as a won't fix.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 7

18 years ago
agreed.  verif. wfm
Status: RESOLVED → VERIFIED
(Reporter)

Comment 8

18 years ago
*** Bug 38532 has been marked as a duplicate of this bug. ***

Comment 9

14 years ago
*** Bug 244967 has been marked as a duplicate of this bug. ***
*** Bug 329097 has been marked as a duplicate of this bug. ***

Comment 11

12 years ago
Here's a use case that our company is running into:

- Suppose maxlength is 10.  
- User enters value "1234567890", the user then saves the value (presumably this is stored in a database). 
- Administrator sets the maxlength of the field to 5.
- User, in passing, edits the page again, exposing the field which will now display "12345".  The user does not know the value that is stored in this field.
- Now user makes other changes to the page and presses save.  The field is saved and unwillingly, the user has truncated the field.  In essence, the browser has went ahead and assumed that the last 5 characters were the ones to remove.

Given this scenario using IE, the user is displayed the entire field to edit, the user can choose how to reduce the size.   If the field is too long, perhaps the page can be redisplayed with an error message or whatever.  The browser makes no assumptions of how to correct the problem, and there is a clear distinction between the initial supplied value of the field (the "value" attribute) and the restriction imposed on user supplied values for the field (the "maxlength" attribute).

Please reevaluate this defect, with this use case in mind.  A "WONTFIX" is not an appropriate resolution.

Thank you for a wonderful browser, however, which I am overjoyed to use.
You need to log in before you can comment on or make changes to this bug.