590554 - maxlength in textarea does not prevent newline characters from being inserted

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[(no longer active)]

Test case:

data:text/html,<textarea maxlength=3>

Try pressing Enter as many times as you want.

Mounir, would you like to take this?

Comment 1

[Mounir Lamouri (:mounir)]

Hmm, it's a layout bug. It's up to the text control frame / editor to block the typing. The content part is working correctly. With the latest nightly, if you type more than 3 whitespaces the textarea will have a red glow (ie. invalid).

I can probably look at that but this isn't going to be high priority considering that is a not-so-harfull edge case.

Comment 2

[Mounir Lamouri (:mounir)]

Would be great to have this bug blocking final/betaN.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Is this actually a layout bug? Looks more like an editor bug.

Comment 4

[Mounir Lamouri (:mounir)]

(In reply to comment #3)
> Is this actually a layout bug? Looks more like an editor bug.

Indeed. I changed the component.

Comment 5

[(no longer active)]

Attachment: Patch (v1)

I recommend that this bug blocks.  Without this patch, the maxlength behavior on textarea's is pretty broken, and I think that we should either take out the maxlength support on textareas for Gecko 2.0 or take this patch.

I only tested this patch on top of my patches to bug 240933.  So I'll land this after I land bug 240933.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 469737 [details] [diff] [review]
Patch (v1)

+    nsAutoString inString(NS_LITERAL_STRING("\n"));

I think this could just be NS_NAMED_LITERAL_STRING

Comment 7

[(no longer active)]

Attachment: Part 2: fix an assertion

This patch caused a couple of assertion failures on the try server.  It turns out that for password fields, nsPlaintextEditor::GetTextSelectionOffsets is called too soon, which causes the assertion to be triggered.  The assertion was masked before because we were counting in the root node incorrectly.  This patch just disables that assertion for password fields.  Note that the computed end offset is correct nevertheless.

Comment 8

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/d5f0467b491d

Comment 9

[(no longer active)]

Oh, and also:

http://hg.mozilla.org/mozilla-central/rev/b1849145f9ed

Comment 10

[(no longer active)]

I backed this out because I had to back out bug 240933.

Comment 11

[[Baboo]]

(In reply to comment #5)
> Without this patch, the maxlength behavior
> on textarea's is pretty broken

It seems to be broken as well on Chrome 6.

Comment 12

[(no longer active)]

(In reply to comment #11)
> (In reply to comment #5)
> > Without this patch, the maxlength behavior
> > on textarea's is pretty broken
> 
> It seems to be broken as well on Chrome 6.

Have you reported this on Chromium's issue tracker as well?

Comment 13

[(no longer active)]

Relanded:

http://hg.mozilla.org/mozilla-central/rev/cceac3c89086
http://hg.mozilla.org/mozilla-central/rev/7b2fbb60e12a

Comment 14

[Daniel C]

Mozilla/5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20100917 Firefox/4.0b7pre

With the test URL in this bug, do the following:

1. Focus the textarea.
2. Press a
3. Press b
4. Press Enter
5. Press c

After step 5 the caret moves to the end of the first line (after b). I think this is unexpected. If step 5 is "Press Enter" the caret doesn't move.

Comment 15

[(no longer active)]

(In reply to comment #14)
> Mozilla/5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20100917 Firefox/4.0b7pre
> 
> With the test URL in this bug, do the following:
> 
> 1. Focus the textarea.
> 2. Press a
> 3. Press b
> 4. Press Enter
> 5. Press c
> 
> After step 5 the caret moves to the end of the first line (after b). I think
> this is unexpected. If step 5 is "Press Enter" the caret doesn't move.

Filed bug 597519 on this.