345704 - cursor jumps to first position when deleting newline

Status: RESOLVED WORKSFORME

(Thunderbird :: Message Compose Window, defect)

Description

[Johannes Buchner]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060723 Minefield/3.0a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060723 Minefield/3.0a1

The cursor jumps to the beginning of the line when trying to join 2 lines.

Reproducible: Always

Steps to Reproduce:
0. Write two lines: 
alpha releases are great
most of the time
1. Go to end of line #1
2. Press Space
3. Press Del




version 3 alpha 1 (20060723)

Comment 1

[Anders Conbere]

WFM Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060721 Minefield/3.0a1

Comment 2

[Mike Cowperthwaite]

I'm confirming this because I've seen it, repeatedly, but I don't have an easy way to reproduce the problem.  One instance where it has cropped up: when I 
have to use a draft message, and I want to restore the lost reflow information on re-reading the draft.  In this case, I start at the beginning of a multiline paragraph and:  <end><del>   repeatedly for each line.  The <end> puts the 
caret after the trailing space on the line, and the <del> deletes the newline and puts the caret at the beginning of the next line.

However, if the last printable char of the line happens to fall in column 72 
(or whatever the wrap point is), the <end> puts the caret between that char 
and the trailing space.  In this instance, I have to <end><spc><del><del>; and when I do this, I will sometimes (using a 3a1 trunk build) see the caret jump to the beginning of the paragraph, I think when the <spc> is typed.

I believe this is an Editor problem, more than a mail-compose issue.

Comment 3

[Johannes Buchner]

WFM too, now. version 3 alpha 1 (20060831)

Comment 4

[Mike Cowperthwaite]

OK, WFM for me too.  Incidentally, the description in comment 2 I think only applied to the trunk prior to the fix for bug 235223; that behavior is better with current trunk builds.  (But not perfect; xref bug 363624.)