Open
Bug 378194
Opened 17 years ago
Updated 3 years ago
Extra (half-existent) newline after Select All, Down in Text Area
Categories
(Core :: DOM: Selection, defect, P5)
Tracking
()
NEW
People
(Reporter: peeja, Unassigned)
References
Details
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.4pre) Gecko/20070419 Camino/1.1b+ Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.4pre) Gecko/20070419 Camino/1.1b+ If you Select All on a text area containing text, press down to move to the end, then type, the new text appears on a new line. The area acts as if there's a newline between the old text and the new, but if the text is copied, the newline does not appear on the pasteboard. Reproducible: Always Steps to Reproduce: 1. Begin with text in a focused text area. 2. Select All. 3. Press down. 4. Type. Actual Results: The new text appears on a new line. Expected Results: The new text should continue from the insertion point at the end of the last existing line.
Comment 1•17 years ago
|
||
This behavior isn't specific to Camino; -> Core for triage.
Component: HTML Form Controls → General
Product: Camino → Core
QA Contact: form.controls → general
Version: unspecified → 1.8 Branch
Comment 2•17 years ago
|
||
confirming. I see this using Firefox 2.0.0.3 on my PPC Mac following the reporter's STR. I was using a bugzilla text field to reproduce.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•17 years ago
|
||
Reproduced on trunk: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a4pre) Gecko/20070420 Minefield/3.0a4pre This is a (slight) variant of bug 125766, using down-arrow rather than right-arrow.
Assignee: nobody → selection
Component: General → Selection
Depends on: 125766
QA Contact: general
Version: 1.8 Branch → Trunk
Updated•15 years ago
|
Assignee: selection → nobody
QA Contact: selection
Updated•13 years ago
|
Assignee: nobody → kaze
Comment 4•13 years ago
|
||
Fabien, this is already fixed on trunk, right?
Comment 5•13 years ago
|
||
Ehsan: right. Works on trunk and even on Fx7.
Comment 6•13 years ago
|
||
(In reply to Fabien Cazenave (:kaze) from comment #5) > Ehsan: right. Works on trunk and even on Fx7. Great! Can you please write a simple test for it? Thanks!
Comment 7•13 years ago
|
||
same question as in bug 125766: • since <textarea>.value strips CR/LF, I guess a Mochitest won’t apply? • is there a way to use enhanced privileges in a Reftest so I could use synthesizeKey()?
Comment 8•13 years ago
|
||
FTR: mochitest + snapshotWindow and compareSnapshot APIs. I’ve included a test for this in the patch I’ve attached to bug 125766.
Updated•12 years ago
|
Assignee: kaze → nobody
Comment 9•3 years ago
|
||
Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority and severity.
If you have reason to believe this is wrong, please write a comment and ni :jstutte.
Severity: minor → S4
Priority: -- → P5
You need to log in
before you can comment on or make changes to this bug.
Description
•