550472 - Handling of previous text differs between "forward" (carets >) and "reply" (lines |)

Status: RESOLVED INVALID

(Thunderbird :: Message Compose Window, defect)

Description

[WBT]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.8) Gecko/20100202 Firefox/3.5.8 (.NET CLR 3.5.30729)
Build Identifier: 2.0.0.23 (20090812)

I'm looking at an e-mail, which is part of a longer conversation, and the various replies-on-replies are distinguished with colored bars on both sides of the message, nested in as far as need be to show the conversation.  When I hit "Reply," these bars remain in the message.  When I hit "Forward," these bars are converted to carets ">" at the beginning of each line, as many as needed to show the depth.  Reply includes a simple heading ("John Smith wrote:") and Forward includes an "------Original Message-------" demarcator followed by a full table of information (including indecipherable "References," which I always delete). 
It's not intuitive as to why there should be a difference here, even for just the bars. vs. carats. 

Reproducible: Always

Steps to Reproduce:
1. Have a conversation with several people, going back and forth about a topic
2. Reply to the message; notice colored bars separating the original (and a simple heading).
3. Forward the message; notice several layers of carats ">>" to distinguish between replies.
Actual Results:  
Bars vs. carats, depending on reply vs. forward.

Expected Results:  
Consistency between the two, ideally with some option to let the user pick which behavior was preferred.

Comment 1

[Ludovic Hirlimann [:Usul]]

Bryan do you think we should change something to be consistent ?

Comment 2

[Bryan Clark (DevTools PM) [:clarkbw]]

I don't think I've ever seen this requested before.  It might make sense to do, I would think it's just a question of engineering and I'm assuming that change wouldn't break any formatting standards.

Comment 3

[Piers]

Hello,

I'd really like the option to have the "------Original Message-------" demarcator inserted when replying as well as forwarding. It makes long conversations between multiple parties clearer. Currently I do this manually.

Adding the table of information as well would be a bonus, just NOT as a table please! I sometimes like to delete out all except the sender line, and it's quicker if it's just text.

Piers.

Comment 4

[Wayne Mery (:wsmwk)]

Do you still see this?
If yes, please attach testcase .eml file.

Comment 5

[WBT]

Attachment: Testcase

The attached .eml file was generated according to the instructions in Comment 0.  It is not something that had to be done by the original bug reporter from over six years ago; anyone could have done this.  

Both Alice and Charlie used the latest release TB in Safe mode.  

To reproduce, open the .eml in TB.  Press Reply to open one compose window, then go back and press Forward to open another.  Compare the contents of the two.  

Some minor differences between now and comment #0 are:
 
>  Reply includes a simple heading ("John Smith wrote:") 
Now it has "On "+datetime+", " before that.

> and Forward includes an "------Original Message-------" demarcator 
Now it's "Forwarded" rather than "Original" before "Message." 

> followed by a full table of information (including indecipherable
> "References," which I always delete). 
The "References" line is now gone when View->Headers->Normal is selected.
It's not surprising that "References" or other headers are there when View->Headers->All is selected, though many headers have been deleted to simplify this particular test case.  

Otherwise, the observed behavior is as described, and this could have been observed by anyone following the steps to reproduce (it doesn't seem like great policy to require an original bug reporter to come back >6 years later to do this in order to prevent the bug from getting marked as INCOMPLETE or UNCONFIRMED, so that the SW can't be improved for other users.

Comment 6

[Wayne Mery (:wsmwk)]

Thanks for the testcase. I tested using 45.1 and nightly build. I confirm the difference, but only when account setting has compose set to respond in html. 

Not confirming because I do not know if this is intended behavior or a duplicate report. But ccing others who might know.


> this could have been observed by anyone following the steps to reproduce (it doesn't seem like great policy to require an original bug reporter to come back >6 years later to do this in order to prevent the bug from getting marked as INCOMPLETE or UNCONFIRMED, so that the SW can't be improved for other users.

Perhaps. But one _might_ think you'd be greatful someone is taking an interest - I could have easily just skipped it considering I've spent considerable time touching over 100 bugs in the last two days and there's no lack of bug I can choose to help.  I get for more problems addressed for bugs with testcases than those without, so attached testcases are better than the best worded description and greatly appreciated by all. As in a picture is worth a thousand words.

Comment 7

[WBT]

I'm glad to see forward action on this particular bug, but I would just recommend a policy change that requests like Comment 4 be addressed more generally than just the original reporter, and that original reporters not responding to such requests not be considered a good reason to close the bug, especially in the absence of attempts to follow the provided steps to reproduce.  In distributed development, it should be OK for a bug reporter to describe things in detail and then disappear; the project should still be able to benefit from those reports.  This policy change would help move things one step closer to how distributed community development should most effectively work.  

The policy change request gets even stronger because of this demonstration that a prompt response reconfirming this same bug, over six years later, with an attached test case confirmed to behave as described, is still not enough to classify the bug as having been confirmed.  Had the request been more explicitly open, and anybody else had confirmed instead, that would have been *more* helpful in moving the bug forward.

Comment 8

[Wayne Mery (:wsmwk)]

Again, to be clear, I'm not confirming (as in, not changing the bug status to NEW) only because I do not know if this is intended behavior or perhaps a duplicate bug report. But ccing others who might know.  In other words, other people are in a better position to act on this. You're welcome.

Comment 9

[Wayne Mery (:wsmwk)]

Jorg, who would know if this is a legit bug?

Comment 10

[Jorg K (CEST = GMT+2)]

Forward and reply as HTML work the same on the supplied test case.