From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020407 BuildID: 2002040708 Reply to a mail message (PlainText). Put the caret at the start of a line that has been quoted and press 'Enter'. Two carriage returns occur, one of which has very wierd behaviour. Reproducible: Always Steps to Reproduce: 1. Reply to a mail message that has more then one line (Plaintext composition) and insert a blank line in the reply. You should see something like this: > Quoted line 1 > Quoted line 3 (after a blank line) > Quoted line 4 2. Move the caret to the start of line 3 (press 'Home'), then press 'Enter'. You will see something like this: > Quoted line 1 > Quoted line 3 (after blank line) > Quoted line 4 3. Leaving the caret where it is, press 'Backspace' twice. The first new line is deleted, but the second one is not. Pressing 'Backspace' again deletes the second new line and the last character of the previous line. Actual Results: (see above) Expected Results: Starting off with something like this: > Quoted line 1 > Quoted line 3 (after a blank line) > Quoted line 4 Moving the caret to the start of line 3 and pressing 'Enter' should add only 1 new line which can then be deleted by pressing 'Backspace'. It should look like this: > Quoted line 1 > Quoted line 3 (after a blank line) > Quoted line 4 A similar problem occurs when the caret starts off at the end of a line, except that after pressing 'Enter', the caret ends up on the first new blank line.
Using the following preferences: Use this font when displaying text messages - Fixed width Style - Regular, Regular Wrap text to fit window width - On Display emoticons - On Forward messages - Inline Automatically quote the original... - On Then - Start my reply below the quoted text For messages that contain 8-bit... - Off Character coding - Western (ISO-8859-1) Send format - Convert the message to plain text
reassign to editir
Assignee: ducarroz → kin
Component: Composition → Editor: Core
Product: MailNews → Browser
QA Contact: esther → sujay
Akkana, Joe tells me you are working on a patch that will do away with the internal span/pre in plaintext emails to fix some wrapping problems? That is everything will just be text in the content tree. That should fix this too no?
Assignee: kin → jfrancis
The bug I'm working on (bug 134439) introduces a new non-wysiwyg "wrap to window width instead of real output width" mode as a temporary measure (on by default) until we can fix all the plaintext editing bugs. It would be a real shame if we decided that our editor just isn't capable of doing wysiwyg plaintext mail editing and never will be ... Personally I'm hoping that the new mode is temporary and that the various bugs on plaintext editing will still stay open (and some day be fixed) even though the new mode will make them not visible by default.
Ya, Akkana is right. I do not intend to close these bugs. I'd still like to get the other plaintext modes working. (Even if I don't really like them myself.)
Most or all of this should be fixed by the patch in 83378
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: fixinhand; patch in 83378
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0.1
83378 has landed on trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
vrfy'd fixed with 2003.04.10 comm bits (plaintext reply).
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.