Mail editor does not handle insertions & deletions correctly at end of wrapped line.

RESOLVED WORKSFORME

Status

RESOLVED WORKSFORME
12 years ago
12 years ago

People

(Reporter: gtoole, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.0.8) Gecko/20061030 SeaMonkey/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.0.8) Gecko/20061030 SeaMonkey/1.0.6

Text inserted at the end of the last word on a wrapped line is not inserted at the  end of the last word;  instead, it is inserted one character later - i.e. at the beginning of the first word on the next line.  Also, using backspace to erase the last character of a wrapped line does not erase the last character;  instead, it erases the (invisible) space to the right of the cursor, causing the last word on the line to be joined with the first word on the next line.

Reproducible: Always

Steps to Reproduce:
1. In SeaMonkey mail, compose a message containing a long sentence which wraps over two or more lines.
2. Place the cursor at the end of the last word on the first (wrapped) line.
3. Type a letter.
4. Place the cursor at the end of the last word on the first (wrapped) line again.
5. Press the backspace key.
Actual Results:  
The letter typed in step 3 appears at the beginning of the first word on the next line.  After step 5, the last word on the first line has been concatenated with the first word on the next line.

Expected Results:  
The letter typed in step 3 should be appended to the last word on the first line.  After step 5, the last character of the last word on the first line should be erased.


Same bug has been present in previous releases (e.g. SeaMonkey 1.0.2, 1.0.5).

Comment 1

12 years ago
The described behavior only exists if the line ends exactly in the wrap column (e.g. 72, or whatever you've set it to).  If the end-of-line occurs before that, the subsequent space is visible when you click <end> and the behavior is as you expect.

This has actually been fixed on the trunk -- if you try a nightly build of Seamonkey 1.5a, you'll see the behavior you expect.  (But see bug 363624.)

I think the fix is a result of bug 235223 and bug 287813.  These are not going to be ported to the branch, so you'll have to either use nightly builds or wait for the official release of Seamonkey 1.5 (or Thunderbird 3.0).
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 2

12 years ago
(In reply to comment #1)
> The described behavior only exists if the line ends exactly in the wrap column
> (e.g. 72, or whatever you've set it to).  If the end-of-line occurs before
> that, the subsequent space is visible when you click <end> and the behavior is
> as you expect.

Thanks for your input, Mike.  You're right that the behavior is correct if <end> is used, but not if the arrow keys are used to position the cursor at the end of the last word on the line.
 
> This has actually been fixed on the trunk -- if you try a nightly build of
> Seamonkey 1.5a, you'll see the behavior you expect.  (But see bug 363624.)
> 
> I think the fix is a result of bug 235223 and bug 287813.  These are not going
> to be ported to the branch, so you'll have to either use nightly builds or wait
> for the official release of Seamonkey 1.5 (or Thunderbird 3.0).

Glad to hear that a fix is in the works.
You need to log in before you can comment on or make changes to this bug.