Closed Bug 1230970 Opened 9 years ago Closed 9 years ago

Long CJK line doesn't not wrap in plain text reply.

Categories

(Thunderbird :: Message Compose Window, defect)

Product:
Thunderbird
Component:
Message Compose Window
Platform:
x86
Windows
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 45.0

People

(Reporter: masayuki, Assigned: jorgk-bmo)

References

Details

(Keywords: jp-critical, regression)

Attachments

(3 files, 1 obsolete file)

Shift reply to this message to see the problem.
2.47 KB, text/plain
Details
Proposed solution (v1b).
1.82 KB, patch
mkmelin
: review+
Details | Diff | Splinter Review
Screenshot for bug 1231917.
116.38 KB, image/png
Details 
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.
Summary: At editing ISO-2022-JP email which has lone lines with "Reply to", the lone line is quoted and not wrapped in the composing window → Long CJK line doesn't not wrap in plain text reply.
Maybe you have different settings and reply to a plain text mail automatically as plain text, I need to use shift reply.
Attached patch Proposed solution (v1) (obsolete) — — Splinter Review 
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.
Assignee: nobody → mozilla
Status: NEW → ASSIGNED
Attachment #8696772 - Flags: review?(mkmelin+mozilla)
Attachment #8696726 - Attachment mime type: message/rfc822 → text/plain
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.
Attachment #8696772 - Attachment is obsolete: true
Attachment #8696772 - Flags: review?(mkmelin+mozilla)
Attachment #8696947 - Flags: review?(mkmelin+mozilla)
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.
Attachment #8696947 - Flags: review?(mkmelin+mozilla) → review+
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.
Keywords: checkin-needed
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.
Flags: needinfo?(mkmelin+mozilla)
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.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 45.0
Comment on attachment 8697405 [details]
Screenshot for bug 1231917.

I can reproduce this now. To be continued in bug 1231917.
Attachment #8697405 - Attachment description: testcase-html-showing.png (not really this bug) → Screenshot for bug 1231917.
Flags: needinfo?(mkmelin+mozilla)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: