268340 - If I paste text past the limit in a multi-line editbox, unexpected behavior ensues

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[Mike Carlson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1

The website is the situation I encountered the problem in. The edit box for
"Card Message" is limited to 250 characters (see URL) - if you paste text into
that edit box through firefox on windows, and that text is larger than 250
characters, you will see the whole message paste successfully. Then if you hit
any key on the keyboard (try an arrow key), you'll see it truncate the text
appropriately. It should have done this immediately when the text was first pasted!

Reproducible: Always
Steps to Reproduce:
1. Go to website above (or presumably any website with a character limit on a
multi-line edit box)
2. Paste text that's too long into the box
3. 

Actual Results:  
Watch it then truncate the text only after you hit a key on the keyboard (while
keyboard focus is on the edit box).

Expected Results:  
The software should have immediately truncated the text when it was pasted - at
no time should a text box display text larger than what it is allowed.

Comment 1

[Mike Carlson]

Actually on examining the situation further, there is some other quirky
behavior. If I try to insert characters in the middle of the text (or at the
end) when the editbox is full, upon hitting the key the box is scrolled to the
bottom, input is immediately focused at the end of the text, the last character
in the text is deleted, and the character typed is put at the end instead.

Now the editbox is put in a strange mode. Typing subsequent characters replaces
this last character with whatever character typed. If I then hit an arrow key on
the keyboard, the last character disappears. If instead of hitting the arrow key
I hit the backspace key, the last character disappears as with the arrow keys,
and the character before that is the one that is actually deleted. It is as
though the last character is just being displayed but isn't really there. For
some curious reason, when this extra non-existant end character is showing, if I
press the "shift" key, the editbox immediately scrolls to the top, however input
focus remains at the end of the string.

In effect, by inserting characters into the middle of the text, I am deleting
the last character of the text, and theoretically I can go about replacing the
entire text without highlighting, hitting backspace or hitting delete by:

1. filling the editbox
2. using the arrow keys to go to the beginning of the text
3. typing one character, then repeating steps 2 and 3 for each additional
character to delete

In summary, I would expect the editbox to NEVER :
1. Show characters at the end that aren't really there
2. Delete characters from the editbox when I haven't highlighted any and I
haven't hit backspace or delete
3. Scroll to the top of the editbox when I hit shift
4. Show text being successfully pasted beyond the limit, when it hasn't really been

And the editbox SHOULD:
1. not respond when I try to insert characters into an already full editbox
(that means no changing my scroll position, input focus, any of the text of the
edit box or even showing extra non-existant characters).
2. Ideally, it would give some sort of notification (possibly audio, ideally
visual) that the editbox is full - however, this isn't necessary to add to fix
this bug.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

This behaviour is caused by javascript and has nothing to do with mozilla's
code. The page author associated the keydown event to a javascript that would
check the length of the field, and cut off anything over 250 characters. There
is no standard way to restrict the text length in a textarea, so people resort
to javascript.

The only problem that may exist here is that keydown event is not sent when
pasting text into the textarea. I do not know whether or not that could be
considered a bug.

Comment 3

[Kevin Brosnan]

*** Bug 359696 has been marked as a duplicate of this bug. ***