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)

PowerPC
macOS
defect

Tracking

()

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.
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
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
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
Assignee: selection → nobody
QA Contact: selection
Assignee: nobody → kaze
Fabien, this is already fixed on trunk, right?
Ehsan: right. Works on trunk and even on Fx7.
(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!
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()?
FTR: mochitest + snapshotWindow and compareSnapshot APIs.

I’ve included a test for this in the patch I’ve attached to bug 125766.
Assignee: kaze → nobody

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.