Closed Bug 102842 Opened 23 years ago Closed 23 years ago

Empty lines doubled

Categories

(Core :: DOM: Editor, defect, P3)

Product:
Core
Component:
DOM: Editor
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: 3.14, Assigned: peterv)

References

Details

(Whiteboard: [serializer][EDITORBASE+]) 

I use Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010913.

When writing an e-mail or news article and typing text between quoted lines,
empty lines are doubled. In more detail:

Assume you have text like this:

> Some line here.
>
> Some other line here.

Now you want to put some text in between, which would look like this in the
composer:

> Some line here.

Your comment.

> Some other line here.

After posting, the empty lines to seperate quotes from your comment are doubled.
Not always, but in most of the cases. I could not figure out the details, when
this occurs and when not.

That is embarrassing, people think you cannot type. BTW: I did enter only one
empty line before this paragraph. It doubled when I typed "That", though.
over to editor
Assignee: ducarroz → kin
Component: Composition → Editor: Core
Keywords: mailtrack
Product: MailNews → Browser
QA Contact: sheelar → sujay
I'm wondering if noone can confirm this. I see it not only in my postings, but
also in many other.

Maybe my summary was not quite correct. It seems that some line endings get
doubled. I just had the case of quoted text which I manually rewrapped. After
posting the two lines were separated by an empty line which was not there before.

This is really a shame on Mozilla. People will argue, it is no better than
Outlook Express:-(

pi
Boris, I see what you are talking about. I think this is related to bug 70728,
giving this to peterv.
Assignee: kin → peterv
Confirming bug since I was able to reproduce it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [serializer][EDITORBASE]
I don't think, it is related to bug 70728. Only one thing sounds similar:
"May be we need to normalize newlines ( rather CRLFs ) in the plain text
serializer."

It could be (I have no idea what's happening in the code), that there is a
conflict how line endings are treated.

pi
Blocks: 108194
In 0.9.6 we have something which *might* be related. Now empty lines are doubled
in display of messages. My naive idea is that there is a complete mess with line
endings of various types.

pi
Isn't this duplicate of bug 67391 ?
Looks related to, but seems not to be a duplicate of bug 67391.

pi
Looking at comment 20 in bug 67391, I'm fairly certain that it's describing the
very same problem as this bug.

Bug 102819 is also about the same issue.
> Looking at comment 20 in bug 67391, I'm fairly certain that it's
> describing the very same problem as this bug.

Yes, but the original description seems to suggest something different.

> Bug 102819 is also about the same issue.

ACK

pi


As bug 102819 and bug 67391 suggest, this is OS independent -> changing OS to all.

pi
OS: Linux → All
Keywords: mozilla1.0
Priority: -- → P3
Target Milestone: --- → mozilla1.0
Is it the following?

From bug 39372:
> - Too much whitespace: Remove all linebreaks at the beginning and and of
> a <pre> block before inserting into the editor.

IIRC, the problem was that a plaintext source like

<example>
Somebody wrote:
> a quote

a reply
</example>
would be turned into something like

<example>
<pre>
Somebody wrote:
</pre><blockquote type=cite><pre>
a quote
</pre></blockquote><pre>

a reply
</pre>
</example>

(I hope, Mozilla's form editor doesn't mess up the lineendins while
writing/posting this.)

This approach has soem logic, since the empty line between quote and reply in
the orginial msg is part of the message/reply. However, another empty line is
added around blockquotes.

It is hard to work around this. Probably, we have to preprocess the content and
remove strip empty lines at the (beginning and) end.

Unfortunately, my interest dropped significantly in the last 2 years, so I
probably wouldn't want to fix it myself (Sorry for not cleaning up my mess!),
unless somebody heavily pushes me to.

If you are talking about something else, please say so.
BTW: If this bug is the one I am talking about, then this is Mailnews: MIME (or
Browser: DOM To Text Conversion, if we want to hack a workaround in the serializer).
>Is it the following?
>
>>From bug 39372:
>> - Too much whitespace: Remove all linebreaks at the beginning and and of
>> a <pre> block before inserting into the editor.

I am not sure I understand that bug correctly. Anyways, this here is not fixed.

>IIRC, the problem was that a plaintext source like
[...]
>This approach has soem logic, since the empty line between quote and reply in
>the orginial msg is part of the message/reply. However, another empty line is
>added around blockquotes.

And that is really bad. Firstly, this contradicts WYSIWYG which ends in bad
looking postings. Secondly, there are good reasons not to have blank lines
between Quotes and added text (like underlining things in quotes). Thirdly, it
does not happen all the time; hence there must at least be an additional problem.

>It is hard to work around this. Probably, we have to preprocess the content and
>remove strip empty lines at the (beginning and) end.

I have no idea how this is handled internally, but it is crucial that (using the
plain text editor) posting get posted as they look in the editor.

>Unfortunately, my interest dropped significantly in the last 2 years, so I
>probably wouldn't want to fix it myself (Sorry for not cleaning up my mess!),
>unless somebody heavily pushes me to.

It is really a pain. And there are problems which could be related. Example:
Start with a quoted text like this:

> This here is the first
> sentence. This a second.
> And a third.

Say I want to spilt quotes and write something in between:

> This here is the first
> sentence.

My text.

> This a second.
> And a third.

The one in front of "This a second." added by hand. There might be an empty line
between those. (Happens sometimes.)

Very confusing.

pi
This bug also seems to be connected to the following effect.
Using the HTML composer for mail/news, when quoting something:

Example:
---------
> blahblahblah
> blahblahyaddayadda

My reply here....
-----------------------
turns into the following when it has been sent:
-----------------------
> blahblahblah
> blahblahyaddayadda
>
My reply here....
-----------------------
and extra ">" is added between quoted and new material.
Is there a bug for this already? (One good thing: You can always see when a user
composed a message in the HTML composer, but I think that wasn't intented, now
was it? :-) )
Referring to my last comment --> Filed bug under #115498.
Regarding #102842...

When composing a message, the doubling of empty lines can be avoided by not
looking at the WYSIWYG editor (which Mozilla does not seem to have), but rather
listen to the keyboard...
-----------------------
A. I reply to a message:
-----------------------
> blah blah blah blah
> blah blah blahblah
-----------------------
B. I hit the RETURN key to create an empty line between quoted text and my new
stuff:
------------------------
> blah blah blah blah
> blah blah blahblah
------------------------
C. Nothing changes at all. The new empty line is not created, so I hit RETURN again.
------------------------
> blah blah blah blah
> blah blah blahblah

My reply text.
------------------------
D. the editor shows one empty line between quoted and new material.
But what I really get is two lines:
------------------------
> blah blah blah blah
> blah blah blahblah


My reply text.
------------------------
E. instead of hitting the RETURN key for a second time I should have trusted my
keyboard, because an empty line was indeed created the first time, but not
displayed.
So at Step B I should have just hit the RETURN key once, not looking at the
editor window (which didn't display the empty line) and start writing my reply:
------------------------
> blah blah blah blah
> blah blah blahblah
My reply text.
------------------------
which when sent looks like this:
------------------------
> blah blah blah blah
> blah blah blahblah

My reply text.
------------------------
--> voila, an empty line.
> it is crucial that (using the
> plain text editor) posting get posted as they look in the editor

Oh, you are talking about the plaintext editor?? I assumed, this bug were about
the HTML composer. If not, then what I wrote is unrealted/offtopic. Please say,
which composer you are talking about.
I know exactly which Bug Boris means: This is clearly a plaintext editor bug!
Just to clarify this: 1)Reply to a message (in plaintext) 2)Hit <enter> within a
quote, voilà, there are two lines inserted. And this is not only a display
error, but they ae also send.
> I know exactly which Bug Boris means: This is clearly a plaintext editor bug!

IIRC, what you call plaintext editor still is the HTML composer. It's all CSS in
Mozilla, what appears plaintext is just the way Mozilla makes use of a
stylesheet. This cold very well be a problem with the HTML input/plaintext
output interface (or something like that). It's definetely not WYSIWYG, more
like WYSIWYGS (S=sometimes).

- Holger
>> I know exactly which Bug Boris means: This is clearly a plaintext editor
>> bug!
> 
> IIRC, what you call plaintext editor still is the HTML composer. It's all CSS
> in Mozilla, what appears plaintext is just the way Mozilla makes use of a
> stylesheet. This could very well be a problem with the HTML input/plaintext
> output interface (or something like that). It's definetely not WYSIWYG, more
> like WYSIWYGS (S=sometimes).

Could be. Just to verify what Sebastian said. Yes, I mean the editor which is
used to send plain text (for all us HTML-haters;-).

This needs to be fixed.

pi
It looks to me as if there's always an extra <br> tag in the composer.
Maybe something like this:
<blockquote type=cite>
blahblahblah<br>
blahblahblah<br>
</blockquote>
<br>
New text...

Just guessing.
> Could be. Just to verify what Sebastian said. Yes, I mean the editor which is
> used to send plain text (for all us HTML-haters;-).
>
> This needs to be fixed.

Yes, I agree. This needs to be fixed soon, those line doubling looks ugly and is
annoying.
Using the HTML editor as a workaround doesn't do any good either, because then
an extra  ">" is added (--> #115498) and with format=flowed disabled the sig
delimeter is defect.
linux build: 2001112012 (0.9.6)
Using the plaintext editor is definitely not WYSIWYG.
wrap set to 72 chars, does indeed wrap @ 72 in the
editor, but newlines are not sent. This is actually good
as you can paste arbitrary text in without it being mutilated.
However if you manually put the newlines in, all hell breaks
loose with missing newlines & extra newlines. It's impossible
to determine what will be sent. Actually what I do is select
the text of the email before sending, paste it into a text editor
window, fix the newline problems (usually delete extra ones),
and paste it back. 

Note not actually sending the (auto) newlines inserted because 
of wrap is bad also. What would be good is to have a vertical
dotted line @ the appropriate wrap column as a visual cue for
people to insert newlines, like:
                                                                        :
                                                                        :
                                                                        :
                                                                        :
                                                                        :
                                                                        :
                                                                        :
                                                                        :

The existing rewrap function can be used on (selected) text if required 
anyway.

Padraig@AnteFacto.com,
I think you mistake format=flowed with bad line wrapping:
http://www.ietf.org/rfc/rfc2646.txt

Add the following line to your userjs./prefs.js and see if it fixes your problem:
user_pref("mailnews.display.disable_format_flowed_support", true);

- Holger
*** Bug 102819 has been marked as a duplicate of this bug. ***
*** Bug 115236 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1+
Whiteboard: [serializer][EDITORBASE] → [serializer][EDITORBASE+]
For 0.9.8 I cannot see this bahavior anymore. Marking FIXED.

pi
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
marking verified per comments.
Status: RESOLVED → VERIFIED
This bug isn't fixed. Two newlines are inserted when I hit Enter key
somewhere in the quotation. I can reproduce with 2002020611/Linux.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
What you discribe is not this bug. You look for bug 123854.

pi
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Boris, FIXED is not the appropriate resolution, when you are not pointing to a
patch. Use worksforme instead.
OK, I reopened bug 102819 which was marked as duplicate of this bug.
<http://bugzilla.mozilla.org/bug_status.html>
FIXED
A fix for this bug is checked into the tree and tested.
WORKSFORME
All attempts at reproducing this bug were futile, reading the code produces no
clues as to why this behavior would occur. If more information appears later,
please re-assign the bug, for now, file it.

marking verified per comments.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.