Closed
Bug 590554
Opened 14 years ago
Closed 14 years ago
maxlength in textarea does not prevent newline characters from being inserted
Categories
(Core :: DOM: Editor, defect)
Core
DOM: Editor
Tracking
()
RESOLVED
FIXED
mozilla2.0b7
Tracking | Status | |
---|---|---|
blocking2.0 | --- | final+ |
People
(Reporter: ehsan.akhgari, Assigned: ehsan.akhgari)
References
()
Details
(Keywords: html5)
Attachments
(2 files)
(deleted),
patch
|
roc
:
review+
roc
:
approval2.0+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
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•14 years ago
|
||
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
Comment 3•14 years ago
|
||
Is this actually a layout bug? Looks more like an editor bug.
Comment 4•14 years ago
|
||
(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 | ||
Updated•14 years ago
|
Assignee | ||
Comment 5•14 years ago
|
||
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+
Assignee | ||
Comment 7•14 years ago
|
||
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+
Assignee | ||
Updated•14 years ago
|
Assignee | ||
Comment 8•14 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b6
Assignee | ||
Comment 9•14 years ago
|
||
Oh, and also:
http://hg.mozilla.org/mozilla-central/rev/b1849145f9ed
Assignee | ||
Comment 10•14 years ago
|
||
I backed this out because I had to back out bug 240933.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 11•14 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.
Assignee | ||
Comment 12•14 years ago
|
||
(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+
Assignee | ||
Comment 13•14 years ago
|
||
Relanded:
http://hg.mozilla.org/mozilla-central/rev/cceac3c89086
http://hg.mozilla.org/mozilla-central/rev/7b2fbb60e12a
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Comment 14•14 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.
Assignee | ||
Comment 15•14 years ago
|
||
(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.
Description
•