STR: 1. Save the attachment as a .eml file 2. Import it to Daily. 3. Select the email. 4. Right click and choose "Reply to Sender Only" Expected Result: The quoted message is wrapped by the editor or forcibly wrapped at quoted. Actual Result: The lone line is displayed as is. I.e., it overflows horizontally (hard to read the line). I guess that this is not a regression actually if such email came from other MUAs. However, this is *new*, this becomes reproducible *only* with Thunderbird.
Thank you for reporting this issue, it is indeed a regression. You mean attachment 8696494 [details] from bug 1230968 (as stated in bug 1230971). I assume that in step 4, you want to "shift reply" to force a plain text reply. If you reply normally, the result is an HTML e-mail with is properly wrapped. This has nothing to do with Japanese or ISO-2022-JP. I can produce the same problem with Korean and UTF-8. Only ISO-2022-JP didn't let you create long lines, now you can. I will attach a Korean message in the next comment.
Created attachment 8696726 [details] Shift reply to this message to see the problem. Maybe you have different settings and reply to a plain text mail automatically as plain text, I need to use shift reply.
Created attachment 8696772 [details] [diff] [review] Proposed solution (v1) Sorry Magnus, I caused a regression in bug 653342. Overzealous forbidding of line breaking is no good in quotes in plain text replies. With this change I re-establish the previous state. In fact, delsp and flowed also don't make sense, we simply ask for formatted output.
Created attachment 8696947 [details] [diff] [review] Proposed solution (v1b). The comment wasn't accurate, so I changed it. The surprising thing is that a so-called plain text message is a HTML document with <body style="font-family: -moz-fixed; white-space: pre-wrap; width: 72ch;"> and wrapping of CJK strings happens there. However, the quoted part lives in a <span style="white-space: pre;"> and is NOT wrapped. So we wrap it in the serialiser as we did before.
Comment on attachment 8696947 [details] [diff] [review] Proposed solution (v1b). Review of attachment 8696947 [details] [diff] [review]: ----------------------------------------------------------------- Yeah this is a really old bug, thx for fixing it! The patch doesn’t change that, but I wonder why the sample message (attachment 8696494 [details]) gets a <br></body> </html> </html> ... showing in the text when replying in HTML compose mode.
Magnus, this is a new regression, not an old bug. Before there was no disallowing of line breaks. With the CJK fix, when I swapped the UseFormatFlowed() to the new call GetSerialiserFlags(), I blindly passed on the serialiser flags. I didn't realise that disallowing of line breaks doesn't make sense here. So now we're back to how it was. This is for plain text replies only, see if (!composeHTML). What do you mean with "really old bug"? And this: <br></body> </html> </html> I don't understand either. Twice </html>, I hope not. Where do you see that? I can't see it in the DOM inspector.
Like comment 0 says, only a regression in the context of thunderbird. Other MUAs have caused this before. I see it in the compose window, inside the quote. The TEXT (not the dom) is showing that inside the quote.
Masayuki logged four bugs at the same time. The comment about the regression was copied from another bug 1230968. This here *was* a regression, clearly. Now the other thing you report I cannot reproduce. I grab attachment 8696494 [details], I HTML reply to it and all I see are the three Japanese characters repeated until the end in a block quote. I don't see this <br></body> </html> </html> showing in the message text anywhere. That would be terrible!! Can you attach a screenshot, please.
You gotta be kidding, you did you create that?? I don't get that. Neither with today's daily (Dec.10) nor with a local build that includes the patch here (which is about plain text, so it wouldn't make a difference).
That's just opening the testcase from command line, then hitting reply. But like I said, this patch didn't make a difference. I'll have to do some more testing to see how tb38 behaves here.
Opening the test case from the command line?? I dragged the .eml file from the desktop into a folder, then hit (HTML) reply. Works the same in 38. I don't see the HTML tags in the reply.
https://hg.mozilla.org/comm-central/rev/3852741463e707989c8660fc7f98d2571603062c Bug 1230970 - Allow line breaking in quotes. r=mkmelin
Comment on attachment 8697405 [details] Screenshot for bug 1231917. I can reproduce this now. To be continued in bug 1231917.