625961 - indentation lost when message text is quoted in reply

Status: RESOLVED WORKSFORME

(Thunderbird :: Message Compose Window, defect)

Description

[Bill Shannon]

User-Agent:       Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.8) Gecko/20100816 Firefox/3.6.8
Build Identifier: 

I tried asking for help about this in the forum but got no response,
so I'm assuming it really is a bug and not a usage error.
http://forums.mozillazine.org/viewtopic.php?f=31&t=2071025

I'm using Thunderbird 3.1.1 with plain text.

When I reply to a message that has indented text such as:

    if (A)
        B
    else
        C


the quoted text in the reply looks like:

> if (A)
> B
> else
> C


If I select the text in the original message before the reply (Ctrl-A),
the quoted text often preserves the indentation properly:

>     if (A)
>         B
>     else
>         C

It's a bug that the behavior isn't the same in both cases and is wrong in
the first case.


Reproducible: Always

Steps to Reproduce:
Do a plain text reply to a plain text message that contains indented text
such as

    if (A)
        B
    else
        C
Actual Results:  
> if (A)
> B
> else
> C

Expected Results:  
>     if (A)
>         B
>     else
>         C

Comment 1

[Ludovic Hirlimann [:Usul]]

Does it also happens in -safe-mode (http://support.mozillamessaging.com/en-US/kb/Safe+Mode)?

Comment 2

[Bill Shannon]

Yes, it fails in exactly the same way in safe mode.

Comment 3

[Ludovic Hirlimann [:Usul]]

One more question did this worked better in 2.0 ?

Comment 4

[Bill Shannon]

Yes, I believe this changed when I converted to 3.x.

Comment 5

[Ludovic Hirlimann [:Usul]]

Hum --- I'm not seeing this (ie if I reply to bugzilla's emails which are plaintext, inednt is kept).

Joe any pref might play a role in this ?

Comment 6

[Bill Shannon]

I'm not seeing it with Buzilla emails either.  For example, the message I
just got announcing your update looks like this when I reply:

[e-mail] wrote on 02/ 9/11 12:21 AM:
> Do not reply to this email.  You can add comments to this bug at
> https://bugzilla.mozilla.org/show_bug.cgi?id=625961
> 
> Ludovic Hirlimann [:Usul ]<[e-mail]>  changed:
> 
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>             Keywords|                            |regression
>                   CC|                            |[e-mail]
> 
> --- Comment #5 from Ludovic Hirlimann [:Usul ]<[e-mail]>  2011-02-09 00:21:42 PST ---
> Hum --- I'm not seeing this (ie if I reply to bugzilla's emails which are
> plaintext, inednt is kept).
> 
> Joe any pref might play a role in this ?
> 

Please try it with a message containing just text as in my example above.

Comment 7

[Joe Sabash [:JoeS1]]

Bugzilla email does not have format-flowed set in the header.
Format-flowed is set by this pref
mailnews.display.disable_format_flowed_support  set to false by default.

I think you will see your problem go away is you set it to "true" no quotes.
However, some folks especially newsgroup posters like to see this protocol enforced. It's main purpose is to wrap text at 72 characters, and our implementation has some bugs.

As an alternative, if you still want to use format-flowed this workaround should work OK.
Start your reply in HTML compose mode.
From the drop-down choose Options>>Format>>send plaintext only.

This should send the mail in plaintext and retain the spacing in most cases.

Comment 8

[Bill Shannon]

Yes, setting mailnews.display.disable_format_flowed_support causes reply
to work correctly.  I guess I'll try that for a while and see if I can
tolerate the side effects.

Why does selecting the text before replying change the behavior?

Starting in HTML mode and then switching doesn't give me what I want because
the text is still being edited and displayed as html text, even if it ends up
getting sent as plain text only.

Anyway, I guess you can consider this another bug against the format=flowed
support.

Comment 9

[Joe Sabash [:JoeS1]]

xref bug 215068 bug 448198 bug 589536
Certainly, I can confirm that the problem exists, but as to the cause/component, most likely a core "problem" in the plaintext serializer.
http://mxr.mozilla.org/mozilla/source/content/base/src/nsPlainTextSerializer.cpp

And that is nothing that anyone is willing to tackle anytime soon.

Comment 10

[David E. Ross]

Re comment #7:  A similar problem occurs if you set 
   user_pref("mailnews.send_plaintext_flowed", true);
and you reply to plain-text E-mail that was not format-flowed.  See bug #448198 (cited in comment #9).  Thus, this work-around is not always valid.

Comment 11

[Bill Shannon]

I just ran into a case where the workaround didn't work.

I have a format=flowed message that included this text:

      <build>
         <sourceDirectory>src/main/java</sourceDirectory>
+        <plugins>
+            <plugin>
+                <groupId>org.codehaus.mojo</groupId>
+                <artifactId>findbugs-maven-plugin</artifactId>
+                <configuration>
+                    <skip>true</skip>
+                </configuration>
+            </plugin>
+        </plugins>
      </build>
      <dependencies>
          <dependency>

The reply text, with the workaround, looks like this:

>        <build>
>            <sourceDirectory>src/main/java</sourceDirectory>
> +<plugins>
> +<plugin>
> +<groupId>org.codehaus.mojo</groupId>
> +<artifactId>findbugs-maven-plugin</artifactId>
> +<configuration>
> +<skip>true</skip>
> +</configuration>
> +</plugin>
> +</plugins>
>        </build>
>        <dependencies>
>            <dependency>

Disabling this workaround and using my previous workaround of selecting all
the text before replying gives the same result as above.

Creating an html reply formats the text correctly.

Comment 12

[Joe Sabash [:JoeS1]]

Yes changing the pref in comment 10 seems to fix that.
The fact that the html reply works points to the plaintext serializer as the culprit here.
So this is probably a dup of one of the bugs in comment 9 But...
Let's get this on the radar... for one thing why would we have 2 separate prefs
mailnews.display.disable_format_flowed_support
mailnews.send_plaintext_flowed 

BTW reading plaintext f-f messages with f-f disabled is ugly to say the least.

cc wayne for possible duping.

Comment 13

[Mason]

Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.18) Gecko/20110320 SeaMonkey/2.0.13

I wrote the following text in the body of a test message:
("N" spaces before the occurence of number "N")

 1  2   3    4     5
  2   3    4     5
   3    4     5
    4     5
     5
000000
 1 1 1 1 1 1
  2  2  2  2  2  2
   3   3   3   3   3   3
    4    4    4    4    4    4
     5     5     5     5     5     5

When I reply to this message, the quoted text becomes:

> 1  2  3  4  5
> 2 3 4 5
> 3 4 5
> 4 5
> 5
> 000000
> 1 1 1 1 1 1
> 2 2 2 2 2 2
> 3 3 3 3 3 3
> 4 4 4 4 4 4
> 5 5 5 5 5 5

I see several issues:

1) leading spaces have been deleted
2) strings of non-leading spaces have been trimmed to a single space
2b) except on the first line where strings of 3+ spaces have been trimmed to two spaces (?!)

I will try disabling all format=flowed functionality.

Comment 15

[rsx11m]

(In reply to comment #9)
> xref bug 215068 bug 448198 bug 589536
> http://mxr.mozilla.org/mozilla/source/content/base/src/nsPlainTextSerializer.cpp

There are actually two patches related to bug 215068 (which I'd consider the primary candidate for the culprit), one 2008-01-05 and 2007-09-29 before.

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=nsPlainTextSerializer.cpp&branch=&root=/cvsroot&subdir=mozilla/content/base/src&command=DIFF_FRAMESET&rev1=1.130&rev2=1.131

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=nsPlainTextSerializer.cpp&branch=&root=/cvsroot&subdir=mozilla/content/base/src&command=DIFF_FRAMESET&rev1=1.124&rev2=1.125

It's hard to tell whether it would be easier to address the individual issues caused by bug 215068 individually here and elsewhere or if a combined fix in bug 448198 would be preferable, but it appears that the whole chunk of issues at once may be too hard to swallow.

Comment 17

[Mason]

Ludovic, bug 625961 is MOST DEFINITELY /NOT/ a duplicate of bug 19471.
Someone with appropriate rights, please re-open.

Comment 18

[Philip Chee]

>  please re-open
Done.

Comment 20

[Jorg K (CEST = GMT+2)]

I created a plaintext message containing this:

    if (A)
        B
    else
        C

Plaintext reply and HTML reply with or without selection maintain the indentation in TB 68. I'm sure this didn't work in the past but got fixed at some stage in the last eight years.