Closed Bug 1355469 Opened 9 years ago Closed 6 years ago

enter key in plain text mail composition should always insert new line

Categories

(SeaMonkey :: MailNews: Composition, defect)

SeaMonkey 2.52 Branch
Unspecified
Windows
defect
Not set
normal

Tracking

(seamonkey2.53 affected)

RESOLVED FIXED
Tracking Status
seamonkey2.53 --- affected

People

(Reporter: bugZ, Unassigned)

References

Details

(Keywords: reproducible)

Attachments

(2 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0 SeaMonkey/2.52a1 Build ID: 20170407004011 Steps to reproduce: 1. Prefs → Mail & Newsgroups → Composition → Default composition format: Body Text (enter key creates new line) 2. Email account prefs → Composition & Addressing: uncheck Compose messages in HTML format 3. Open new message window 4. In the content area type any text, e.g. line 1 5. Press the enter key (to start a new line) 6. Press the enter key again (to start a new paragraph with a blank line between) Actual results: The cursor flashes but did not advance to a new line. Expected results: The cursor advances to a new line with a blank line above it. The enter key now has to be pressed a third time to advance to a new line. When the enter key behavior pref is set to new paragraph, the cursor behavior is as expected: each press of the enter key advances to a new line. This behavior began with the April 5 trunk build, April 4 behaves as expected.
This known problem should have been fixed in latest builds. Please try Build 20170424132653 or later and leavea comment concerning your results.
Flags: needinfo?(bugZ)
OS: Unspecified → Windows 10
Blocks "Bug 1354931 - inconsistencies with cursor and new lines in reply window"
Blocks: 1354931
User agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0 SeaMonkey/2.52a1 Build identifier: 20170430002034 1. Prefs → Mail & Newsgroups → Composition → Default composition format: Body Text (enter key creates new line) 2. Email account prefs → Composition & Addressing: uncheck Compose messages in HTML format The enter key still does not always cause a new line. It has to be pressed 3 times to get a blank line between paragraphs: - the first press advances to a new line - the second press does nothing - the third press advances to a new line
Flags: needinfo?(bugZ)
NOT reproducible with unzipped installer of official en-US SeaMonkey 2.53a1 (NT 6.1; WOW64; rv:56.0) Gecko/20100101 Firefox/56.0 Build 20170706013410 (Default Classic Theme) on German WIN7 64bit. Fixed? WIN10 only? Add-on or something else dependent? I haven't a clue.
There were numerous problems in 2.52 with this. It should be fixed by now in 2.53.
I believe the problem still exists, though there are apparently certain conditions under which it happens - it's pretty consistent with email coming from AOL and some other (MS Exchange?) users. Difficult but maybe not impossible to reproduce. Will follow up after I have time to test recent nightlies.
2.54+ is broken in textdecoder jsmime. Fix is still not in the tree. This breaks mail. I put a workaround in my local one. If you can reliably reproduce it with 2.53 post it here. I can provide a 2.53 if you need one. 2.49.1 should also contain the latest fixes. First candidate is up but only for Linux right now. Its missing a fix for html signatures but this one is a little obscure and not relevant here. FRG
Effect is accidentally reproducible for me with unzipped installer of official en-US SeaMonkey 2.53a1 (NT 6.1; WOW64; rv:56.0) Gecko/20100101 Firefox/56.0 Build 20170706013410 (Default Classic Theme) on German WIN7 64bit. I think I will have found out STR, soon. @reporter: "3. Open new message window": how exactly do you do that? Click [Compose]?
Keywords: reproducible
OS: Windows 10 → Windows
STR with unzipped installer of official en-US SeaMonkey 2.53a1 (NT 6.1; WOW64; rv:56.0) Gecko/20100101 Firefox/56.0 Build 20170706013410 (Default Classic Theme) on German WIN7 64bit: 10. Composition preferences have to be as per original report 11. From Browser menu 'Window → Mail and Newsgroups' 12. In Email Client Thread Pane click Message your received from Bugzilla for my Comment 8 13. Click [Reply] 14. <Ctrl + Pos1> to bring flashing caret to top left position in email contents pane (Left from "On 10/4/2017 11:49 AM, Bugzilla@Mozilla wrote:") 15. <enter> » Caret and all text behind it moves 1 line down 16. <enter> BUG: no visible changes see (a)! :-( a) The <enter> without any visible effect (step 16) Changes end of source from [Compose]?<br> &gt; <br> <br> </body> </html> to [Compose]?<br> &gt; <br> <div><br> </div> <div><br> </div> <div><br> </div> </body> </html> b) only effective <enter> like step 5 add additional "<br>" behind "<body>" c) I am not sure concerning possible DUPs from <https://bugzilla.mozilla.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=DUPs1355469&sharer_id=41036> @Reporter: c)This one seems to be "#4" in your "Bug 1354931 - inconsistencies with cursor and new lines in reply window" ?
Status: UNCONFIRMED → NEW
Ever confirmed: true
See Also: → 1354931
I am unable to test either the latest 2.54 or 2.55 Win32 or Win64 - they all crash when I start mail-news with my regular profile. I am currently running Build identifier: 2.54a1 20170811005712, which is the last usable build before Data Manager got horked. Mail-news doesn't crash, but the newline issue persists when replying to certain messages. Are there any files I need to remove so I can upgrade to a newer build?
This appears to be fixed in 2.56, both new mail composition and replying with plain text mail are adding newlines every time the enter key is pressed.
I can confirm this for 2.53, build 2018-11-25 x64 on Win10 1809 (from http://www.wg9s.com/ ). Seamonkey 2.56 and 2.57 don't work for me, the mail-news windows are completely blank. Even with a new profile. 2.54 and 2.55 (tested long time ago) crashed right out of the box. Switched back to Seamonkey 2.49.5 x64 and everything is fine again, didn't even need to restore my profile.
As far as i see it I backported every available patch for 2.53 in this area. Could someone try with TB 60. Mail in 2.57 is being fixed up but it will still take some time. FRG
As for Seamonkey 2.53 x64 build identifier 20181210134801 the bug seems to be nearly fixed (on Win10 x64). It only happens in one case: Reply to an html email, and start you reply ABOVE instead of below. But using shift-enter in that case gives me the expected result. I personally don't need a fix, I can live with that. Switching to TB 60 is not an option, it lacks so much usability since it tried to clone Outlook Express.
Seamonkey 2.53 x64 build 20181210134801 It seems to work as expected for me, also Win10 x64. Anxiously awaiting fixes to 2.57...

This is still happening with Seamonkey, though now I checked and found the setting it depends on:
Version:
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.1
Build-Identifikator: 20191026130006

It is depends on the setting: mail.compose.default_to_paragraph
When it is set to "false" = default, it shows the behavior that you have to hit enter twice on an empty line when replying above the HTML mail.
When it is set to "true" = now default it behaves the "right way", though that settings shouldn't influence that part and all previous SM versions (2.49.x and older) didn't need that setting to be "true".

(In reply to Frank-Rainer Grahl (:frg) from comment #13)

As far as i see it I backported every available patch for 2.53 in this area.

Could someone try with TB 60. Mail in 2.57 is being fixed up but it will
still take some time.

FRG

Tested TB17.0, TB24.0.1, TB31, TB38.0.1, TB45, TB52.0.1, TB56b4 and TB60 with mail.compose.default_to_paragraph=false (when available) and doesn't display the issue. Will continue to go back to see if I can find it not working in TB.

Looking at email reply source before changes and then after going to the On part and pressing return twice.
Before any changes:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 01/04/2020 10:00 pm, Fred Bloggs wrote:<br>
</div>

Reply with SM:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 01/04/2020 10:00 pm, Fred Bloggs wrote:<br>
</div>

Reply with TB:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix"><br>
<br>
On 01/04/2020 10:00 pm, Fred Bloggs wrote:<br>
</div>

As you can see, SM is adding an extra <div> rather than inserting the <br> elements within the existing <div>

Attached file test case

With this test case if you position the cursor at the start of the "On" , in SM it adds extra <div>s but in Firefox it adds extra <br>s within the existing <div>

Trying test case against various applications and versions:
SM 2.49.5 fine
Firefox 56 broken
Firefox 57 broken
Firefox 58.0b3 fine
Firefox 58.0.2 fine

Now with Firefox 58.0a1 nightly builds:
2017-10-02-22-02-04 broken
2017-10-03-22-01-38 broken
2017-10-04-22-03-09 fine
2017-10-07-22-01-56 fine
2017-10-12-22-01-11 fine
2017-10-22-22-01-03 fine
2017-11-12-22-03-46 fine
Fix window:
https://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2017-10-03+22%3A00&enddate=2017-10-04+22%3A00
To me it looks like Bug 1390562 fixed this test case. I will add the patches and test it fixes mailnews too.

Tested that it does fix mailnews, pushed to 2.53.2b1 tree and kicked off rebuilds.

Wohoo, fixed!
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.3
Build-Identifikator: 20200402130008
http://www.wg9s.com/comm-253-de/

Fixed in the upcoming 2.53.2 Beta 1. If not please reopen.

Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: