STR: 1. Open a composing window. 2. Select ISO-2022-JP in [Options] -> [Text Encoding] -> [Japanese (ISO-2022-JP)]. 3. Copy "テスト" without quotations. 4. Paste the Japanese word a lot of times Expected Result: Each line shouldn't be wrapped unless it reaches right side of the window. Actual Result: Each line is forcibly wrapped with max column settings. Due to this behavior, users cannot imagine actual email which is displayed on the receiver's MUAs. Maybe, fixing this bug might fix some other bugs.

First of all, if you copy the text from Bugzilla and insert into an e-mail, you get a long line that isn't broken, since the text is inserted into a <pre> block. So copy the text first to, say, Notepad++, so it loses the HTML and then copy it. Indeed, the text is wrapped to the *window*, as it always has been. Nothing about this has changed. You can see the behaviour in attachment 8689008 [details] (sorry, in Korean, but same deal). That's the standard browser behaviour for CJK languages and that won't change. The change me made for e-mail sending is that we transmit exactly what the user entered, and it's displayed the same way the user entered it at the recipients side, of course also wrapped to the window. What do you mean by? Each line is forcibly wrapped with max column settings. It's only wrapped when sending if you set mailnews.send_plaintext_flowed to false. Can you please explain and/or supply screenshots of what you mean.

(In reply to Jorg K (GMT+1) from comment #1) > First of all, if you copy the text from Bugzilla and insert into an e-mail, > you get a long line that isn't broken, since the text is inserted into a > <pre> block. Oh, indeed. > So copy the text first to, say, Notepad++, so it loses the HTML and then > copy it. Yes, that's what I expected! > Indeed, the text is wrapped to the *window*, as it always has been. Hmm, no, I don't the line which has "テスト" continuously is wrapped automatically. I tested again even with other encodings. Then, I can reproduce this bug even with Unicode or Western. I guess Thunderbird checks OS locale or something. > The change me made for e-mail sending is that we transmit exactly what the > user entered, and it's displayed the same way the user entered it at the > recipients side, of course also wrapped to the window. My point of this bug is, not wrapped by window's edge, wrapped with fixed columns. > It's only wrapped when sending if you set mailnews.send_plaintext_flowed to > false. I checked mailnews.send_plaintext_flowed, but it's true...

(In reply to Masayuki Nakano [:masayuki] (Mozilla Japan) from comment #2) > My point of this bug is, not wrapped by window's edge, wrapped with fixed > columns. Which window are we talking about? The mail composition window? There is no wrapping, at least not for me, look! Oh, I just saw your image, how do you get this wrapping???

Oh, I forgot to say, I tested with composing window for plaintext email. I cannot reproduce this bug with composing window for HTML mail.

Sorry, that's the thing people don't understand. There is no plain text. Plain text is HTML with style "white-space:pre-wrap; width=72;" behind the scenes. So Gecko does the wrapping for you. I'd mark this bug invalid ;-) BTW, thank you so much for testing this. Out of the four bugs (bug 1230968, bug 1230970, bug 1230971, bug 1230974) you raised, you found two real new problems and one pre-existing but quite annoying one, bug 1231017. Great! Please retest bug 1230971 with tomorrow's Daily and report back with an image.

(In reply to Jorg K (GMT+1) from comment #6) > Plain text is HTML with style "white-space:pre-wrap; width=72;" behind the > scenes. Ah. > So Gecko does the wrapping for you. That sounds too bad since the editor behavior does NOT indicates new behavior (format=flowed,delsp=yes") to Japanese users explicitly. With the new behavior, if user wants to keep old style, they need to change the pref or explicitly insert line breaks manually. I guess that latter users must be majority in such user groups. For them, it's important not to wrap lines per 72 columns. Current behavior makes such users send emails which includes unexpected long lines. > I'd mark this bug invalid ;-) So, I don't agree with INVA. I'm not sure if this is fixed by easy, but I believe this should stay open. > BTW, thank you so much for testing this. np, Thank *you* for working on such long standing bugs!

Cc'ing Makoto-san, IIRC, he's known something around editor of composing window. I think that if composing window will send email with format=flowed, each line should be wrapped at window's edge, i.e., editor should ignore the column settings.

Look, writing a flowed plain text mail like so: 1234567890123456789012345678901234567890123456789012345678901234567890** <============================= 72 =====================================> huhu huhu huhu huhu huhu huhu huhu huhu huhu huhu huhu huhu huhu huhu huhu huhu huhu huhu huhu huhu huhu huhu huhu huhu huhu huhu huhu huhu will look like two lines in the "plain text" composition window. Due to the beauty of flowed transmission, it will be received as one long line. That's always been the case. If you don't want that, switch off flowing. (In reply to Masayuki Nakano [:masayuki] (Mozilla Japan) from comment #7) > Current behavior makes such users send emails which includes > unexpected long lines. "unexpected" is one way to phrase it. But as far as I understand it, Japanese users *always* wanted long lines to be transmitted unbroken. To do this in plain-text mail with ISO-2022-JP and CTE 7bit (!!), you must use flowed and delsp=yes, that's what people asked for since the year 2000, see bug 26734. Now you come along and use the "plain text" composition and tell us that it doesn't work well with the idea of long lines. Simple: Don't use "plain text" composition, use HTML composition and as long as you only add text, the message will be auto-downgraded to plain text upon send. In my many years of using TB, I've never composed a plain text message, I've only ever sent plain text replies with "shift reply" in extreme cases where the received HTML message needed to be "cleaned". I think this really isn't an issue ;-)

If the plain text composing should never be used, how about removing the feature? It is confusing to have a never-to-be-used feature.

I'm changing the summary, to make it crystal clear what the issue is. This has nothing to do with Japanese or ISO-2022-JP. It affects *all* plain text e-mail which will be sent with format=flowed. This is a ux-consistency issue since what is displayed in the composition window, that is, wrapped text, is not what the recipient will see.

(In reply to Jorg K (GMT+1) from comment #9) > Now you come along and use the "plain text" composition and tell us that it > doesn't work well with the idea of long lines. Simple: Don't use "plain > text" composition, use HTML composition and as long as you only add text, > the message will be auto-downgraded to plain text upon send. > > In my many years of using TB, I've never composed a plain text message, I've > only ever sent plain text replies with "shift reply" in extreme cases where > the received HTML message needed to be "cleaned". > > I think this really isn't an issue ;-) In Japan, mainly elder people don't like to receive HTML mail especially in business scene. A lot of people claimed (or still claim) that HTML mail isn't good for security. Technically, most of them do not make sense. However, one of business manner in Japan is, everybody should write plaintext emails because they were taught business manner from such elder people. For example, according to this document: http://www.sc-p.jp/news/pdf/150701PR.pdf over 80% people are still using plaintext email in business scene in Japan. (Q5 in the document) Additionally, IIRC, number of Japanese users of Thunderbird is No.2 in the world, so, plaintext email support is still important.

I agree with all of that. We should maintain the possibility to send plain text e-mail. And we do! In fact, we just made it much better: No more spurious spaces and you can send flowed. As I said: Don't use "plain text" *composition*, use HTML *composition* and as long as you only add text, the message will be *auto-downgraded to plain text* upon send. Your compatriot said: (In reply to Masatoshi Kimura [:emk] from comment #10) > If the plain text composing should never be used, how about removing the > feature? It is confusing to have a never-to-be-used feature. Please note the difference between plain text *composition* and plain text format being sent.