Test case: data:text/html,<textarea maxlength=3> Try pressing Enter as many times as you want. Mounir, would you like to take this?
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: --- → ?
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
Status: NEW → ASSIGNED
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 on attachment 469737 [details] [diff] [review] Patch (v1) + nsAutoString inString(NS_LITERAL_STRING("\n")); I think this could just be NS_NAMED_LITERAL_STRING
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+
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
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 → ---
(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: 9 years ago → 9 years ago
Resolution: --- → FIXED
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.