Closed Bug 111245 Opened 23 years ago Closed 23 years ago

Word wrap doesnt always work (MailNews reply compose)

Categories

(Core :: DOM: Editor, defect)

Product:
Core
Component:
DOM: Editor
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: hramrach, Assigned: kinmoz)

References

Details

Attachments

(1 file)

screenshot of the end of lines not working right
1.98 KB, image/gif
Details 
Mozilla 0.9.6 Win32
When I edited reply to a post the text was kept on a single line although I have
word wrap (after 76 chars) enabled. When I hit enter to terminate the first line
the other lines were wrapped as expected. But when I wanted to delete the CR
between the first and the following line a letter on one of the lines was
deleted instead. Looks like the CR was omitted somewhere form something?

It has maybe something to do with the fact I started to write under the original
text. I should investigate this more closely sometime for better isolation of
the problem.
Joe has some other bugs like this.  He has some fixes in his tree that should
make this work a lot better (I don't know for sure that they'll fix your
particular case since you didn't say where you clicked or what you did).  We
also talked about adding a style to the quoted sections to make them visibly
different, e.g. make them blue or italic or something, so at least it will be
obvious when this sort of thing is happening.
To reproduce:
1) run Mozilla News
2) go to a newsgroup ( I use n.p.m.ui )
3) open a post
4) press button to reply to it
5) when the original is displayed quoted in the new message window, select (with
mouse) the bottom of the original message including any empty lines following it.
6) type something. The line is never wrapped. When you hit enter, two nwe lines
are created, not just one.

This way it seems to be reproducible quite reliably.
This is only plaintext mail, right?  In html mail, you would see the blue bar and 
know you where inside the quote.  

I'm not sure yet if this is really a bug.  I've been told repeatedly to allow 
deletion and typeing inside mailquotes, and that is what you are doing.  Akkana, 
any thoughts?

The problem is not the fact you can edit the original mail. It's OK and would be
a bug if you couldnt. THe problem is word wrap doesnt work under some
circumstances if you do edit the quoted text.
The quoted text isn't supposed to word wrap; we obey whatever wrapping the
original author used.  (Otherwise, we get unevenly wrapped lines with every
other line consisting of one word.)

You should be able to break quoted text by clicking or selecting part of the
quoted text and hitting return; this should put you outside of quoted text and
anything you type should wrap.  It sounds like you're not hitting return.  We
assumed people would hit return because otherwise your reply bumps up against
the quoted text and it's hard for the reader to tell where your reply starts.

If you aren't doing that, then we have a conflict: you want your new typed text
to be outside the quoted text, but we've had other vocal users (jar, and maybe
brendan?) who felt very strongly that they should be able to edit the quoted
text, and just typing something inside a quoted block shouldn't start a new line
and put them outside the quoted text.

I don't know how we can satisfy both sets of requirements at once.
Moz 0.9.6 Linux Non HTML Editor - reply to mail

Word wrap is set to -say- 72. You have received a mail that is much wider than
this. You start to type a reply at the top - ie above the existing text. As you
enter text the text below scrolls down - *but only the first 72 cols*. The
columns to the right remain put. Assuming your mail is long enough, if you then
scroll to the bottom and back up, the 'stranded' right hand parts of the line
have been joined to the correct left hand parts again. On transmission, the
message seems OK.
I'm experiencing the same thing as the reporter in 0.9.6 on Red Hat Linux 7.2.
According to Akkana, the words should not wrap if they're on a quoted line. But
I'm experiencing this on the line immediately after the quoted text. For example:

> This is part of the quoted text.
>
This is a line that I type that is not wrapped.

Even if I hit enter on that line and continue, the new line will not be wrapped.
It looks as if Mozilla expects a blank line by itself to turn back on word wrap;
this is counterintuitive. From a user's point of view, word wrap should be in
effect on any line not beginning with a quote character.
*** Bug 113118 has been marked as a duplicate of this bug. ***
The layout engine doesn't care what character is first on a line, and has no
mechanism for having different behavior based on the first character.  The
layout engine only knows which text is wrapped inside a node or not, and the
problem here is that sometimes the line you type is inside the same node that's
used for the quotation, even though it doesn't look to the user like it's part
of the quotation.

Joe and I talked recently about adding something to the node which would change
color or style (e.g. blue italics) for the quoted portion, so at least it would
be obvious to the user when he's typing and it's going inside the quoted
portion.  I personally think we ought to do this and that it would help a lot. 
(We should probably look at the mail/news pref for style for quoted messages in
the message display window, if that still exists.)
Italics is fine but no more fixed colors, please. I alredy cant read mail
headers because they are blue and cant be changed (as far as I know).
This screenschot shows how the end of the two lines of quoted text do not
move down when adding new lines above them, they do not move up either when
deleting lines above them. After refreshing (by minimize-unminimize or similar
actions) the ends of the lines are in the correct place again. In this same
message I experienced several related bugs. Wordwrap did not work anywhere in
the document, but when I manually wrapped text bij hitting enter, it would
sometimes immediately add an extra empty line. This also happened the other
way around, where hitting backspace at the start of a line would not delete
that line
Bits of the page failing to scroll is an unrelated bug (unless that's what you
were talking about all along, but it didn't sound like it).  Someone on #mozilla
said they were going to file a bug about that a few days ago, but I never saw
the bug itself so you'll have to search.
It seems to me that although these are several different bugs, they are not
unrelated. Word wrap not working, bits not scrolling and the incorrect behaviour
for adding/removing linebreaks all seem to be cause by replying to a message with
long lines. (perhaps lines longer than the wordwrap line length?)

This shouldn't be caused by users typing inside the quoted text, I'm sure I haven't
done that (I always keep at least one empty line between quoted text and response) 

BTW: Some of this behaviour reminds me of bugs in much older versions of the
Mozilla mail composer, which had trouble with linebreaks too back then.
Herman, what version/buildID of mozilla were you using when you reported the 
update problems above? I'm curious because I fixed a big repaint problem in the 
0.9.6/0.9.7 timeframe (bug 97674).

So is the original reported problem still a problem?
I'm using 200202117 now.
It seems there is no problem with recent versoins :)

I cannot close report, please do so.
Oops. Build ID is 20020117.
Marking fixed.  If anyone's still seeing this in a recent build, please reopen.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Confirmed fixed on the latest build (2002012903). The official 0.9.7 release
still suffered the problem when responding to the same email, but in the latest
nightly it works for me.
verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: