Closed Bug 83378 Opened 23 years ago Closed 22 years ago

Wrapping problem in plain text reply

Categories

(MailNews Core :: Composition, defect)

defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.0.1

People

(Reporter: bugzilla3, Assigned: mozeditor)

References

(Blocks 1 open bug)

Details

(Whiteboard: [adt3] fixinhand; need r=sr=,EDITORBASE+)

Attachments

(3 files, 2 obsolete files)

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
QA Contact: sheelar → 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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: ui
*** 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. ***
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
I expect this is a dup of several related bugs that Joe has on his plate.
Blocks: 108194
*** 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?
Keywords: nsbeta1
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)
Target Milestone: mozilla1.0 → mozilla1.0.1
*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
Keywords: mozilla1.0
Target Milestone: mozilla1.0.1 → mozilla1.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.
Assignee: ducarroz → jfrancis
Status: ASSIGNED → NEW
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.
OS: Windows 98 → All
Hardware: PC → All
Marking nsbeta1+
Keywords: nsbeta1nsbeta1+
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
Whiteboard: [adt3]
Keywords: mozilla1.0mozilla1.0+
nsbeta1-. Engineers are overloaded with higher priority bugs.
Keywords: nsbeta1+nsbeta1-
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].
Target Milestone: mozilla1.0 → mozilla1.0.1
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?
Attached patch patch to editor rules code (obsolete) — — Splinter Review
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.
Status: NEW → ASSIGNED
Attached patch editor patch — — Splinter Review
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.
Attachment #83875 - Attachment is obsolete: true
Attachment #83876 - Attachment is obsolete: true
Whiteboard: [adt3] → [adt3] fixinhand; need r=sr=
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".
Blocks: 102819
Whiteboard: [adt3] fixinhand; need r=sr= → [adt3] fixinhand; need r=sr=,EDITORBASE+
Keywords: nsbeta1-nsbeta1+
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.
Attachment #84236 - Flags: superreview+
fix landed on trunk; we may want to tweak where the css lives or what the css
is.  after getting feedback from users.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
2002061304-trunk/Linux freezes on hitting Enter key at the middle
of a line. And the caret doesn't move.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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
Severity: normal → major
Blocks: 152144
Blocks: 133741
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
Blocks: 153649
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.
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
nsbeta1-. The fix is too risky for the 1.0 branch.
Keywords: nsbeta1+nsbeta1-
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.
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
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. 
Status: RESOLVED → VERIFIED
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)
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: