From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9+) Gecko/20010529 BuildID: 2001052920 Perhaps this bug is a duplicate of bug 24930 but the latter became so complicated that I am not quite sure about what discussion there is intended for. Anyway, in any message with long text (say more than 20 lines), replying text is often not wrapped. This usully happens when starting to reply from the lower part of the original text. Resolution is to use Options->Rewrap. Reproducible: Sometimes Steps to Reproduce: 1. Reply to a plain text message, using maximised window and plain text format. 2. Try to insert a very long sentence, somewhere in the lower part of the original message Actual Results: Line is not wrapped, even if it is longer than the width of the maximised window (preference was wrapping plain text at 85 chars). Expected Results: Line is wrapped without the need of Options->Rewrap command.

change->esther

I have also seen this problem in 2001060511 - it happens sporadically for me, though. I have been trying to reproduce the problem but I cannot come with a scenario when it happens.

*** Bug 89197 has been marked as a duplicate of this bug. ***

Hi, Its easy (at least for me) to reproduce the bug (succeed everytime): 1) Reply to plain text message 2) Go to the next line of last line saying > in the beginning of line, DON'T PRESS ENTER! 3) Write text. It doesn't wrap. If that doesn't work, try selecting some of the quoted text, delete/cut it and type without pressing enter first. Should have same effect. If you hit enter where I said DON'T, text wraps fine. My settings are: start below the quoted text, wrap at 72 characters.

WFM, On Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2+) Gecko/20010709, when i select a message and hit the reply button, the message window appears and automatically, one line is wrapped below the >quoted text.

Marking NEW based on duplicate.

*** Bug 84320 has been marked as a duplicate of this bug. ***

*** Bug 92670 has been marked as a duplicate of this bug. ***

*** Bug 90905 has been marked as a duplicate of this bug. ***

I expect this is a dup of several related bugs that Joe has on his plate.

*** Bug 110754 has been marked as a duplicate of this bug. ***

*** Bug 101685 has been marked as a duplicate of this bug. ***

I can also reproduce this everytime -- when I reply to any plain text message and try to delete text from the bottom of the message to trim up the email -- stops wrapping text. Furthermore, the scrolling of text doesn't seem to refresh after that. If I add text to the top of the message the text below will often "leave behind" some of the characters on the right (they stay on the screen until drag the side slidebar with my mouse) only the last one or two characters on the line are affected. This also seems to happen when trying to edit longish (more than two paragraphs) entries in text entry boxes in the browser. This becomes really annoying when you are used to replying at the end of a message and get lots of messages from people using outlook (replying on the top) because you often want to edit the text to go under their most recent reply. In my case (and large office) almost all my emails lose their wrap beacuse I have to edit the text of the respondant.

Jean-Francois, does this need to be reassigned to Joe?

I would say either joe or akkana.

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)

*spam* Moving these bugs target milestones back to Mozilla 1.0 as they're listed in a tracking bug for fixes essential for 1.0

*** Bug 106228 has been marked as a duplicate of this bug. ***

*** Bug 106428 has been marked as a duplicate of this bug. ***

reassigning to Joe.

is the behaviour from comment 13 - leaving behind those characters on the right while scrolling text - the same bug as this one? I have been seeing this forever and still see it using 2002010721/linx. It looks pretty weird ...

This is my most disliked bug in 0.9.7. Just started on 0.9.8, haven't seen it yet but haven't looked hard. It is semireproducible for me; happens a few times a day, during heavy emailing. Scenario always same as curtis@liminis.com reports: I Reply to a message, plain text, inline quoting, begin below. There is a lot of trash I don't want to quote, so I delete some of it with the keyboard: Shift-Up for a while, Delete. I think this happens mainly when replying to something in the middle of other text. Then I press Enter or just move down (not sure) and start replying, so it looks like this, more or less: ---%<--- Somebody wrote: > Blah blah blah. x x x x x x x x x x x x x x x > x x x x x x x x x. This is where my cursor is, at the end of this line -> > x x x x x x xx x x x x x x x x x x x x x > some more stuff I will reply to soon... -- My Signature ---%<--- I continue to type on the indicated line and it does not wrap. Workaround: move down to the next line, retype (do not copy/paste!) the line, and it will begin wrapping. Later, delete the original unwrapped line. E.g.: ---%<--- Somebody wrote: > Blah blah blah. x x x x x x x x x x x x x x x > x x x x x x x x x. This is where my cursor was, and I started to type a really long line...damn! This is where my cursor is now, and I started to type a really long line, but now it wraps correctly because I started the paragraph over again. > x x x x x x xx x x x x x x x x x x x x x > some more stuff I will reply to soon... -- My Signature ---%<--- My layman suspicion: something in the composition window keeps a sticky text attribute for quoted inline text saying "I come from the original text message, don't wrap me" so that the quoted stuff stays formatted as it was before. Normally this attribute is off for text you type. But when you insert a newline in the middle of a quoted block, it keeps the attribute on. This would explain why starting a new paragraph works fine. Possible? If I figure out how to reproduce this on a fresh message, I will attach details... BTW I also see the bug about garbage characters on the right after scrolling, is this filed somewhere?

OK, I think I have it reproducible. 0.9.8 (2002020415), Modern look, RH Linux 2.2.12 Gnome Enlightenment. Message composition settings: auto quote when replying, start my message below, wrap at 72 characters. Always send plain text. Have a signature file (a couple of lines). Go to news://news.netbeans.org, subscribe to netbeans.modules.openide.dev. Today, Tue Feb 5 12:18 AM my time, there is a message from J. Xue "Re: [openide-dev] API Support 2.10.2". It looks like this: ---%<--- I'm using 3.3.1, which I installed by unzipping the archive on top of 3.3. But the first time I installed the api support module was after that. -J.X. "Jesse Glick" <jesse.glick@sun.com> wrote in message news:netbeans.modules.openide.dev/3C5ED258.3060708@sun.com... [various other stuff below here...] ---%<--- I hit Alt-R to reply. Cursor appears at the bottom of the message with all this stuff quoted, just before a blank line and my sig. I hold down Shift and move up until the whole quoted garbage is selected, up until but not including J.'s two lines of actual text, and press Delete; it is gone, cursor left just below J.'s second line. I press Right Arrow. (Pressing Enter would insert two newlines. Is this filed elsewhere??) Now the screen looks like this: ---%<--- J. Xue wrote: > I'm using 3.3.1, which I installed by unzipping the archive on top of 3.3. > But the first time I installed the api support module was after that. <<cursor here>> -- Jesse Glick <mailto:jesse.glick@sun.com> NetBeans, Open APIs <http://www.netbeans.org/> ---%<--- (Interesting note: when I copy the mail window and paste in this textarea, the result has only two blank lines, not the three I can see. Display bug?) Note that the cursor is on the middle blank line. I type an 'x'. Immediately the cursor jumps up one line (!) and the 'x' appears: ---%<--- J. Xue wrote: > I'm using 3.3.1, which I installed by unzipping the archive on top of 3.3. > But the first time I installed the api support module was after that. x<<CURSOR HERE>> -- Jesse Glick <mailto:jesse.glick@sun.com> NetBeans, Open APIs <http://www.netbeans.org/> ---%<--- Clearly I did not want the 'x' there, so I move back (Left Arrow), press Enter. Two spaces are inserted. Sigh. Press Right Arrow, Delete, End. (Again just pressing Delete does not appear to delete anything - newlines are completely screwed up.) Now looks like this: ---%<--- J. Xue wrote: > I'm using 3.3.1, which I installed by unzipping the archive on top of 3.3. > But the first time I installed the api support module was after that. x<<CURSOR HERE> -- Jesse Glick <mailto:jesse.glick@sun.com> NetBeans, Open APIs <http://www.netbeans.org/> ---%<--- Now I start typing SPACE 'x' SPACE 'x' etc. It just keeps on going, no wrapping: ---%<--- J. Xue wrote: > I'm using 3.3.1, which I installed by unzipping the archive on top of 3.3. > But the first time I installed the api support module was after that. x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x<<CURSOR HERE>> -- Jesse Glick <mailto:jesse.glick@sun.com> NetBeans, Open APIs <http://www.netbeans.org/> ---%<--- The textarea may have line-wrapped this but in the composition window the x's go on and on, and the horizontal scroll bar appears to hold them. After selecting Alt-P R to rewrap, the paragraph is wrapped, and typing more text seems to correctly keep on wrapping it.

Note that in some messages - but not all - selecting Rewrap (either by keyboard or mouse) causes my X11 cursor to get "grabbed" and not released. I.e. pointer turns to back-left-pointing arrow, and the mouse can still be moved but the X display accepts no further input events whatsoever. For a particular message and set of edits, this seems to be reproducible, but it does not happen with all messages; not sure what the trigger is. The only fix is to log in on a console and kill Mozilla (then the cursor is OK again). Since there is not a safe workaround for this bug, I would consider it pretty important; I am considering a downgrade to Mozilla 0.9.7 because of it. Makes day-to-day sending of mail much more difficult: 75% writing, 25% trying to wrestle the composition window into putting a newline where I asked for it.

Rewrap hanging is a different and unrelated bug, 121046, recently fixed.

ah-ha! here you are my pretty! i've found you at last! this is the biggest problem with plaintext compose, imho, and makes us look like amatures.

Marking nsbeta1+

The problems associated with line-wrap anticipation are getting cleaned up, but there's still a problem with trailing spaces on a line. It happens for me when replying to mail with the default variable width or with fixed width text. My reply is defaulted to reply above quoted text. I'm not sure of all the conditions that trigger this, but one way to see it is: Reply to a message. Start typing text until the text wraps in the middle of a word; i.e. the partially typed word relocates to the next line. Backspace/delete through the word up to and including the first letter. The partial word will bounce back to the previous line at wrap point. When you delete the first character of the word, the cursor will jump back ove r the space to the end of the previous word. Note that this does not happen (on the first line typed) with backspace/delete until line wrap has occurred. From this point (cursor at end of word, space undeleted) type a new non-space character. The space is restored quietly and the character appears after the space. Repeat the process, but type an initial space before the glyph character. Two spaces occur between the glyph and the previous word. Repeat the process (cursor at end of word, before undeleted space. Backspace/delete. The glyph immediately before (and the undeleted space) are deleted. Type a glyph character. The glyph appears without an intervening space.

There are still serious problems with the editor when inserting text within quoted text. In addition to the spurious linefeed problem and the disappearing space, ther is a spurious space problem. In circumstances which I have not isolated, moving the cursor off a line in the middle of composition and later moving it bakc to the insertion point, when a space has already been typed at the end of the current line, displays two spaces at the end of the working line. Backspace/delete on the last space rubs out both spaces, and leaves the cursor immediately after the last glyph character. Another serious problem concerns the spurious linefeeds. Again, I haven't tracked this down completely, but in some circumstances when there is a spurious linefeed displayed at a boundary between inserted text and following quoted text, the cursor cannot be down-arrowed past the end of the inserted block. It simply cycles through the inserted text; sometimes the whole of it, sometimes a sub-set (possibly delimited by yet another spurious display linefeed.) One side effect of this is that it is impossible to extend a block selection (by Shift-down or Shift-right) beyond this point in order to, e.g., override the intensely irritating default proportional spacing on all inserted text.

adt3 per adt triage

nsbeta1-. Engineers are overloaded with higher priority bugs.

I'm curious what would be considered "higher priority bugs". The is the one "real" bug I see with Mozilla on a daily basis, and it is as annoying as a sore thumb.

I wonder that too. This the only reason I don't use mozilla. Even crashes would be easier to comprehend than odd behavior in simple text editor. This bug prevents writing completely, crashes would do it only sometimes.

The problem here is that people are typing in the mailquote without realizing it. This isn't an editor bug, it's a perception issue. I recommend that we show a blue bar for mailquotes always: even in plaintext. Either that or we soft wrap everything, including the mailquote.

You have got to be kidding. To the casual user (even to this not-so-casual) user, there is no rhyme or reason to when things wrap and don't wrap. I don't really even know what a mailquote is. It sounds to me like something I would expect to find in the HTML-ized mail editor, not something in the *plain text* editor. To quote comment 26 "this is the biggest problem with plaintext compose, imho, and makes us look like amatures." This isn't acceptable behaviour, no matter what the underlying reasons are and I doubt it would be acceptable even if there was some sort of "blue bar"

I'm missing something here. Some (long) time ago, my plaing text editor disappeared. *All* of my mail composition takes place in an htmlized editor, and is converted to plain text to be sent, according to my preference settings. I have a blue bar, and my editing is a total shambles. I have not found any setting in the Composition panel of mail & News that will bring back a plain text editor. If there is one, please let me know.

I agree - this should be a high priority bug. If Moz crashes once in a while I can put up with it, but it is really tiresome to mess around with line wrapping, and bizzare linebreak behaviour. I'd prefer a what you type is what you get - simpler, but far more effective than something that tries to be clever but fails monumentally! A lot of people including myself find it useful to be able to add text in the middle of a quoted message without the strange editing effects.

Peter: the prefs to switch between html and plaintext compose are in your mail account settings: there's a checkbox that says "Compose messages in html format" which controls which editor gets brought up. Joe: it is an editor problem, because people are ending up with their caret in the mailquote after splitting it, when the caret should end up outside it, or they're getting their caret in the mailquote when clicking on a blank line near where they split it. We need to make it difficult for users to get the caret into the mailquote (i.e. it should only happen if they click somewhere on a quoted line, or on a blank line between two mailquoted lines in the same mailquote, i.e. not a place where the user hit return to split the mailquote). The user should never be able to click on a blank line at the beginning or end of a mailquote and end up inside the mailquote, and as long as that's possible, we will continue to get dups of this bug. I do agree that making the mailquote visually obvious would at least help users realize when this is happening, and a patch to do that would be helpful to get people by if there's no chance of getting a real fix. I don't suppose the mail quote settings under "Mail and Newsgroups / Message Display" are also applied to a compose window, by any chance? (They should be, but that would probably have to be a mail fix from ducarroz.) And it's academic anyway, because those prefs aren't remembered (I just tried changing them in a build from today, and when I dismissed the prefs window then brought it back, they had reverted).

Eric writes: "I don't really even know what a mailquote is. It sounds to me like something I would expect to find in the HTML-ized mail editor, not something in the *plain text* editor." Exactly. You don't know. If there were a colorful blue bar marking the mailquote, you *would* know. That's why I say this is a perception issue. That also addresses Akkana's point. I know there are blank lines sometimes at the end of mailquotes - I mentioned this to mail folks in a different bug (100643). I havent' had a chance to investigate why that is (is mail putting it there? Intentionally? Accidentally?), but there is no real defense against that *unless the mailquote is highlighted in some way*. Until then this bug will never really close. There could be instances where the editor is screwing up, and I could fix them, but we will always get dups of this bug until the users acan tell when they are in a mailquote or not. Unless we do what I wanted to do a long time ago, and either softwrap everything or hard wrap everything (ie, scroll until user types return) in plaintext. If the quotes and the rest of the text behaved the same, this wouldn't be an issue. They should behave the same. it's either that or the blue bar. Take your pick.

Found the html setting in the account settings. I can see why it's there, rather than in preferences, but it's mighty confusing. It probably deserves a comment in the Preferences->Mail & Newsgroups->Composition pane. Aside from that, it doesn't work for me. The setting resolutely refuses to stick, even between invocations of the Mail & Newsgroups Account Settings... in the same mail session. Another bug?

Peter: it sounds like there's a new bug on mail prefs not being remembered; I encourage you to file that, or search to see whether it's already filed. (Hwaara on IRC said there was one like that fixed a few months ago, but didn't know of a current one.) You can always edit your prefs manally: exit the app, then edit prefs.js in your profile directory, look for the mail prefs, and you'll want a line that looks something like: user_pref("mail.identity.id1.compose_html", false); (for whichever mail id you want to change). If the prefs dialog itself is overwriting it, try putting the line in user.js (create one if you don't already have one) instead of prefs.js, and then it won't get overwritten.

"Exactly. You don't know. If there were a colorful blue bar marking the mailquote, you *would* know." I'd know there was a funky blue bar, but not how it worked. I seem to remember some time ago having fits with one of these blue bars, trying to get rid of one which was quoting nothing in the middle of a message. So, I'm very skeptical that this will make things easier. Regarding soft or hard-wrapping: "it's either that or the blue bar. Take your pick." I'd take soft wrapping (or auto hard wrapping) everything. Frankly, when I choose "plain text compose" I'm thinking this should behave pretty much like a unix terminal compose program (say pine). I get an 80 column by n-row area to type in and what I see on the screen is exactly what gets sent out.

Hey, Eric agrees with my "hard wrap everything" plan. I'm no longer alone in the world! :-) The blue bar would indeed help in general even if it wouldn't help Eric. This is because most users realize that the bar indicates the quote. This is backed up by bug data: we get a lot fewer bug reports about mailquoting edit woes from html mail users.

What other mail clients (Eudora, Outlook) do to avoid this issue? If they use a simpler approach, we shouldn't raise additional problems by supporting a feature no one else has and that is so hard to fix. As for Outlook Express 6, I tested it for a while and found the following, when appending characters inside a mailquote (at any point): 1. BEHAVIOUR OF COMPOSE WINDOW It doesn't make the line to wrap immediately on the predefined compose wrap preference. What it does is to wrap when the width of the line exceeds the boundaries of the compose window (soft wrap). Mozilla doesn't make anything in this case, the horizontal scrolling bar appears. Imo, this the greatest annoyance and should be addressed before 1.0. Everyone who have used another mail client will notice it. 2. FORMATTING OF SENT MESSAGE The message contains hard returns at the point where wrap preference for sending was exceeded. I 'm not sure if we want that. Anyway, it is a minor issue, since the default preference on receive window is to always wrap text to fit window width. As for the blue bar, imho it's ridiculous to have one because of an inability to make things work as expected. Period.

What Netscape 4 did was make the compose window non-wysiwyg. The text in the compose window wrapped to the width of the compose window (and if you made it narrow enough, quotes wrapped as long-short-long-short), whereas at send time, the non-quoted part of the message was wrapped to the wrap column, which usually was narrower than the compose window. For Mozilla, we had the option of making the compose window be wysisyg, and wrap at (or at least close to) the place where the message will be wrapped at send time. The downside of that is that quotes have to be treated specially, because they're wrapped differently to prevent the long-short problem. I suppose one possible solution to our current problems, if we've given up on fixing the editor bugs, is to go back to the non-wysiwyg compose window like NS4 had. But it would seem a shame to give up wysiwyg because we can't make our editor's selection work right. Or we could make the non-wysiwyg mode available on a pref (perhaps even make it the default until this bug is fixed). If anyone reading this would like to see this happen, please file a bug on me asking for it. It would be quite easy to do -- I could probably throw a patch together in a day if it was something people wanted.

So, if I correctly understand what Akkana says, NS4 behaves much like Outlook does (while I was a NS4 user for years, I can't recall it's behaviour, sorry!). Thus, I strongly support the idea of returning to non-wysiwyg mode and I filed bug 134439 on it. But I am not in position to evaluate Akkana's patch, since all my latest attempts to compile Mozilla has failed. Let' see how many votes or cc's it will get...

RE: Comment #45 From Akkana, I agree with this solution. Since I was one of the original filers on this bug, I'm much rather see something that works as the default. Add the glits when you get the basics down. Programming 101.

Akkana, Thanks for the tips, but I have user_pref("mail.identity.id1.compose_html", false); already. Is this the appropriate preference?

Moving to Mozilla1.01 since it is nsbeta1- and [adt3].

Instead of pushing this annoying daily bug back to 1.01, is it possible to make an imperfect fix in 1.0 which will lower the priority of this bug, and then clean it up in 1.01?

The above patches are a work in progress on improving plaintext mailquote woes. I still think we should go with Akkana's solution and ditch plaintext mailquotes altogether and have it all be plaintext. The css changes I made belong somewhere else, but much to my surprise there doesn't seem to be any mail-compose specific css file. The css changes make plaintext mailquotes have blue text. This will clue the user in when they are typing in a mailquote that perhaps they need to split it first. The rules changes make it less likely to end up with a blank line that is inside a mailquote. This diff also fixes bug #102819. Ditto for the changes to the InsertAsQuotation() code.

This patch has actual testing and I have fixed all sorts of problems in it. I think this represents a huge leap forward in how well the editor deals with plaintext mailcites in a reply. Please try it out! Remember to apply the css patch as well. seeking r,sr in order to get this on the trunk for widedspread testing.

I definitely approve of the html.css patch in principle. In practice, though, it doesn't seem to be working here; after applying both patches and rebuilding in layout and in editor/libeditor, I still don't see quotes in blue. Does it work for other people on non-mac platforms? For the rest: I don't seem to be seeing the original behavior in my pre-patch build, so I hope some of the people who are hitting this will be testing it to see if it solves the problem.

Comment on attachment 83874 [details] [diff] [review] patch to layout/html/document/src/html.css style nit: use blockquote[type="cite"] span[_moz_quote="true"] pre[_moz_quote="true"]

> Suggestion: put mailquote display rules in EditorContent.css I was thinking that it was actually a good thing that the mailquote rules applied everywhere, so messages look the same in the browser (and mail window?) as in the reply window. Normal html content won't have these special tags -- they'll only be there when displaying a mail message.

I applied editor and html.css patches (without attachment 84612 [details] [diff] [review]) and it worked as expected (or at least this is what I think) on Win2K. Mailquotes are blue, no newlines are added when pressing enter at the right or left end of a quoted line. The blue color trick is still a hack but now it's more difficult to write inside a quote. And I am very happy that finally jfrancis didn't implemented those ridiculous blue bars in plaint text reply.

"no newlines are added when pressing enter at the right or left end of a quoted line" I meant to say "only one newline is added when pressing enter at the right or left end of a quoted line".

I applied attachment 83874 [details] [diff] [review] and attachment 84236 [details] [diff] [review], and made a Linux build. It works fine.

Comment on attachment 84236 [details] [diff] [review] editor patch sr=kin@netscape.com with the following: --- Need to initialize aHandled to PR_FALSE in SplitMailCites(). --- Correct "ned" typo in the following comment: + // then we will ned a 2nd br added to achieve blank line that user expects.

fix landed on trunk; we may want to tweak where the css lives or what the css is. after getting feedback from users.

2002061304-trunk/Linux freezes on hitting Enter key at the middle of a line. And the caret doesn't move.

comment 65: it only freezes for a number of seconds. Is there a bug for this: we're going to start seeing dupes soon. It's rather high profile...

So, is the patch here the one that introdced blue quote text? (Not that I'm complaining -- I quite like the differentiation from normal text) However, I would think that the quote text color would be syncronized with the color set in Edit -> Preferences -> Mail & Newsgroups -> Message Display -> "Use the following settings when displaying quoted plain text messages", right? Or, is that a separate bug?

jfrancis, Have you check-in "nsWSRunObject.cpp" part of your patch? On 2002061504/Linux, caret doesn't move to next line after I hit enter key. Is this behavior caused by that?

In a few seconds freeze, my debug build outputs assertions many many times. ----- ###!!! ASSERTION: looking beyond end of text fragment: 'Not Reached', file nsWSRunObject.cpp, line 880 Break: at file nsWSRunObject.cpp, line 880 -----

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020619 Just to confirm previous reports: Now this is serious. If I have quotes and put the cursor of the end of the line, then press enter it takes about seven seconds (sic!) before the new line is added. Further, the cursor remains in the quoted line. This is much worse than before. Bug 102819 has been marked fixed due to this patch, which is kind of true, but the situation got worse, as I described. Since this behavior makes the plain text editor look like it crashed and stops workflow for several seconds I mark it MAJOR. pi

If this is really the patch causing these freezes, why isn't it backed out by now ? It's not quite a blocker but it makes trying to use mailnews /really/ painful. jfrancis, we need you !

jfrancis was away on vacation. I'm back now. I'll look into this. Can the folks who see this problem give me any more details? Is this any time you hit return in a mailquote? Or is it only with certain messages? Obviously, I did not see this problem before (or I wouldn't have landed it) so I'm worried that I won't be able to reproduce it.

Welcome back, not what you wanted to see on your return I expect :) It happens with any message (I don't use mail, only news). For example, the message "Netscape 6.2.3/Mozilla Performance Improvement" in n.p.m.unix. I click reply, then place the cursor just after : > overall graphics performance. These are the two values that were > changed in order to achieve better performance. (before the quotemark >) and press return. This then causes a 5/6 second hang (actually pegging the CPU at 100%). I'm on Linux CVS trunk of a couple of days ago. Let me know if profile results during the hang can help you.

Adding to comment 70: Press RETURN anywhere in a quoted line, at the very beginning, in the middle or at the end. It will cause a huge delay. Mail and news does make no difference, but that is what you would expect anyways. pi

I've filed bug 153649 on the perf issue (before realizing it was being discussed here).

I can repro this, though not nearly as badly as the linux users on older boxes have it, which explains why it escaped my attention before. On my macosX box I can get a delay of almost a second. I'm closing this out since this is really a new bug: further activity will be in bug 153649.

As I investigate this, I see that current (6/25/02) trunk builds on both osX and macos9 are not behaving correctly when typing return in plaintext mailquotes. No blank line is being created when hitting return in middle of plaintext mailcite. Also, though you get a blank line when hitting return at end of a line of mailcite, typing on that blank line is inside mailcite. This stuff worked (and still works) in the tree I used to land this from. I'm starting to suspect a botched landing. This is seperate from the perf problems (which i see to a mild degree even in the tree I landed from). Reopening this bug to fix correctness issues.

nsbeta1-. The fix is too risky for the 1.0 branch.

Fix checked in. The patch I had attached here (which is what I used to check in, though I missed a file) was the wrong version (read: unfinished). Meanwhile I had the right version on my main machine and of course didnt see any problems. Sorry for the snafu. Should be all better now.

I am noticing something like this in trunk build 20020908... twice in two days, I have replied to a plain-text message, and my typed reply has gone past the point where it was supposed to wrap. If I do not hit enter to break the line, it just keeps going. I do not know if this is a new bug or an extension of that one... I am a bit reluctant to open a new bug, as most of the ones I have entered have been duplicates, despite my efforts to search for the bugs first.

Using trunk build 20021119 on winxp, mac osx and linux. It's easier to see now that the quoted text is blue. You know the wrapping won't happen if the text you are typing is blue. 1.) Original scenario still happen if you insert the long sentence within the quoted text without hittin <Enter> 2.) Comment 4 still happens, but only if the cursor is placed somewhere within the quoted text, <Enter> is not used, and you start typing. 3.) Comment 5 always worked because the automatically inserted line is outside the quoted text. 4.) Comment 13 sounds like the editing is happening with the quoted text too, but may have been part of a different problem that is fixed, it's really old. 5.) Comment 22 is fixed if the reporter hit <Enter> like stated and it didn't allow the text to wrap. Hitting <Enter> now within the quoted text will put you on a new line and wrap text. "Just movie down" still doesn't work at this time. 6.) Comment 23 is still a bug when deleting and just pressing the back arrow. Pressing <Enter> at this point now works fine, it leaves you at the current line but you are out of the quoted text area so the newly typed line will wrap. 7.) Comment 28 I'm not seeing this anymore. Typing text at the automatic reply location then backspacing over all of the newly typed text after wrapping takes me to the beginnig of the automatic reply location without seing a partial word bounce back to the previous line at wrap point. So this appears to be fixed. 8.) Comment 29 partially fixed but part still a bug as noted above. 9.) Comment 56, we now see quotes in blue tested with trunk 20021119 to make it easier for uers to discover the quoted text 10.) Comment 65 & 66 doesn't happen anymore 11.) Comment 68 is fixed, I see the new line with <Enter> 12.) Comments 70 through 79 are reporting hangs due to a fix that went in for the origianl bug, but was fixed and no longer happens. 13.) Comment 80 is still a bug and brings this bug full circle back to the originally stated bug where typing text within the quoted text does not wrap. We have 2 new more streamlined bugs for the outstanding issue within this bug so I will verifiy this as fixed for showing the quoted text in color so user will know when they are within "mailquote" and for fixing the bug introduced in comments 70 through 79 where we would hang after pressing <Enter>. The new bugs for editing within mailquote not wrapping and not correctly marking quoted text as such when you break a line are 161968 and 161969. If anyone has a new scenario that doesn't match the description in the 2 bugs mentioned above please open a new bug, this bug has too many scenarios now.

Given that typing text within mailcites is not SUPPOSED to wrap, are there any scenarios left that are actually bugs?

If you determine that bug 161969 is the way it's going to work, then the only outstanding bug is 161968 unless any of the contributors to this bug comes up with a new scenario.

Another related issue - bug 155622: Wrapping information lost on "Edit as new", "Edit draft" (RFC 2646 format=flowed)