Note: There are a few cases of duplicates in user autocompletion which are being worked on.

maxlength in textarea does not prevent newline characters from being inserted

RESOLVED FIXED in mozilla2.0b7

Status

()

Core
Editor
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: Ehsan, Assigned: Ehsan)

Tracking

({html5})

Trunk
mozilla2.0b7
html5
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(blocking2.0 final+)

Details

(URL)

Attachments

(2 attachments)

Test case:

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

Try pressing Enter as many times as you want.

Mounir, would you like to take this?
Blocks: 535043
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.
Component: DOM: Core & HTML → Layout: Form Controls
OS: Mac OS X → All
QA Contact: general → layout.form-controls
Hardware: x86 → All
Would be great to have this bug blocking final/betaN.
blocking2.0: --- → ?

Comment 3

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

Indeed. I changed the component.
Component: Layout: Form Controls → Editor
QA Contact: layout.form-controls → editor
Assignee: nobody → ehsan
Blocks: 240933
Status: NEW → ASSIGNED
Keywords: html5
Created attachment 469737 [details] [diff] [review]
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.
Attachment #469737 - Flags: review?(roc)
Attachment #469737 - Flags: approval2.0?
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
Attachment #469737 - Flags: review?(roc)
Attachment #469737 - Flags: review+
Attachment #469737 - Flags: approval2.0?
Attachment #469737 - Flags: approval2.0+
Created attachment 470541 [details] [diff] [review]
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.
Attachment #470541 - Flags: review?(roc)
Attachment #470541 - Flags: review?(roc) → review+
No longer blocks: 240933
Depends on: 240933
http://hg.mozilla.org/mozilla-central/rev/d5f0467b491d
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b6
Oh, and also:

http://hg.mozilla.org/mozilla-central/rev/b1849145f9ed
I backed this out because I had to back out bug 240933.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 11

7 years ago
(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.
(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?
blocking2.0: ? → final+
Relanded:

http://hg.mozilla.org/mozilla-central/rev/cceac3c89086
http://hg.mozilla.org/mozilla-central/rev/7b2fbb60e12a
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → FIXED

Comment 14

7 years ago
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.
(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.
You need to log in before you can comment on or make changes to this bug.