豪勢なコメントをいただけて驚いています。
皆様ありがとうございます。

コメントを踏まえ、設定を見直すなりアドオンを使うなり、今一度頭をひねりたいと思います。


>> WADAさん


[quote="WADA"]
Thunderbirdのテキスト形式でのメール編集は、内部的にはHTMLでの編集であって、"white-space: pre-wrap "を指定してあって、テキスト入力以外は一切させないだけ。
今回の現象は、HTML形式で編集している時だと"white-space: pre"を使っているので問題が起こらなくて済んだということ。
Delivery Format=Plain Text Onlyに変えればテキスト入力しかさせないから、もう一度HTMLモードに戻せる、ということを除けば、テキスト形式での編集とほとんど変わらない。
[/quote]

そうだったんですね。内部処理までは知りませんでした。
ただ、「Delivery Format」はメール作成画面における[オプション] > [送信形式]の設定のことですよね？
だとすると毎度変更するのは手間なので、アドオンで対応する事になりそうです。確かに慣れと言えば慣れなのですが。


>> 偶然的通行人さん
補足ありがとうございます。
その辺りの知識にはまだ足を突っ込めませんが、いつか見返した時に貴重なヒントとして理解できるくらいになっているといいなと。


>> meeyarさん
[quote="meeyar"]
質問者の方が「HTMLで編集かぁ…」といった反応なので、
[/quote]
リアルな反応もそれそのままでしたよ。私の事を見ていたんですか（笑）
ともかく、アドオンを教えていただいてありがとうございます。

外部エディタを使うという発想が無かったのですが、
今回の件とは関係無く、このアドオン使えそうですね。
テキストエディタ側の資産（機能や何らかの作り込み）が活用できるので、効率化・省力化が図れますね。
こういうシンプルで応用を利かせるタイプのアドオン大好きです。

[quote="偶然的通行人"]この場合、メッセージを書いていく部分は BODY 要素で定義されていますが、この BODY を DOM Inspector で見ると、DOM Node には「style="font-family: -moz-fixed; white-space: pre-wrap; width: 72ch;"」という定義があるのは、Bug 1193153 内で指摘されているとおりです。[/quote]
その通りでして...
で、"Caused by bug 1174452"とバグサマリーにあるようにbug 1174452が原因の模様。
そして、bug 1174452は、”white-space: pre;”の時の問題なのに、
(Bug 116083、Bug 1151873、Bug 1174452 のどれも、"white-space: pre;"の時の問題)
何でまた、”white-space: pre-wrap;"を使うThunderbirdのテキストモードのコンポーザーではBug 1193153の問題が起こって、
"white-space: pre;"を使っているはずのThunderbirdのHTMLモードのコンポーザーでは問題が起こらないのか、
というのが謎。
"white-space: pre-wrap; "でも"white-space: pre;でも共通のモジュールの変更の影響で、
どの段階のパッチがThunderbirdにあたっているかで現象が変わる、ということかもしれません。

[url=https://bugzilla.mozilla.org/show_bug.cgi?id=1193153]Bug 1193153[/url]そのものの解決ではありませんが、質問者の方が「HTMLで編集かぁ…」といった反応なので、別の回避策を書いておきます。Thunderbird内のみで完結しないため、邪道かもしれませんが。

[url=http://globs.org/articles.php?lng=en&pg=2]External Editor[/url]というアドオンを入れておくと、メール本文を外部の任意のエディタで編集可能です。
外部エディタでコピペやスペースの制御が可能なので、本Bugの影響を受けず、テキスト形式のままでのメール作成が可能です。

アドオンの設定画面でエディタのある場所をフルパスで記入し、「このエディタはユニコードを扱える」にチェックを入れます。
Win7のメモ帳(notepad.exe)なら「C:\Windows\System32\notepad.exe」です。
[size=1]※%windir%\system32\notepad.exeでは動きません。[/size]
「ヘッダの編集」にもチェックを入れておきます(入れないと文字コードの変換にしくじるケースがあるため。改変の必然性はありません)[attachment=0]ee.PNG[/attachment]

メール作成画面の「表示→ツールバー→カスタマイズ」でエディタのアイコンを任意の場所に表示させておきます。アイコンを押した時点でエディタが開き、本文の編集が可能です。
書いたら上書き保存→×でエディタを閉じると、Thunderbirdのメール作成画面にメール本文がコピーされます。文字の折り返しは、エディタで改行したもの＋Thunderbirdの既定(mailnews.wraplengthの値)に従います。

シロウトのたわごとかもしれませんが、横から失礼します。

本件の現象は、プレーンテキスト形式で開いた Thunderbird のメッセージ作成ウィンドウで、連続する複数のホワイトスペース（半角スペース文字やタブ文字）を含んだ文字列のコピーをおこなうときに、ホワイトスペースがどのように取り扱われているか、という問題のように感じられます。
参考としていえば、一つ前のメジャーバージョンである Thunderbird 31.8.0 では、本件の問題は発生しません。

メッセージ作成ウィンドウで入力したり返信で引用された文字列の、初期状態の表示としては、連続する複数のホワイトスペースは維持されています。
しかし、その文字列をコピーした段階で、複数のホワイトスペースが１つにまとめられるという結果が生まれるケースがあります。（したがって、ペースト先ではホワイトスペースが省略された状態で貼り付けられます。）

この内容は、表示における white-space プロパティの働きのうちホワイトスペースに関わる動作としては、normal 、nowrap 、pre-line と同等のように見えます。pre と pre-wrap では、ホワイトスペースはあるがままの状態が維持されます（改行／折り返しの扱いには差があります）。

ところで、Windows 版の Thunderbird 38.3.0 での動作をざっと確かめた結果は次の通りです。

新規にプレーンテキスト形式のメッセージ作成ウィンドウを開いたとき、本件のような症状が起こるのは、最初の質問で詳しく述べられているとおりです。
この場合、メッセージを書いていく部分は BODY 要素で定義されていますが、この BODY を DOM Inspector で見ると、DOM Node には「style="font-family: -moz-fixed; white-space: pre-wrap; width: 72ch;"」という定義があるのは、Bug 1193153 内で指摘されているとおりです。
white-space: pre-wrap; の表示条件から類則するなら、少なくともホワイトスペースは維持されそうなものですが、実際にはコピー時に省略されてしまいます。

興味深いのは、[返信] で開いたプレーンテキスト形式のメッセージ作成ウィンドウです。
引用文（つまり引用符付きの文字列）に存在する「連続する複数のホワイトスペース」を含む文字列をコピーしても、ホワイトスペースの省略は起こりません[b](*)[/b]。
引用文は、メッセージ作成ウィンドウの内部的には、地の文とは異なる定義（SPAN によるスタイル定義）がおこなわれているようです。
DOM Inspector で対象を見たとき、この SPAN の DOM Node には「style="white-space: pre;"」の定義があるのがわかります。
（ホワイトスペースや改行・折り返しを可能な限り原文のママにするという、引用の基本前提を考慮しているからだと考えられます。）
しかし引用とは違う、ユーザーが書いた地の部分（BODY 直下）では、本件のような症状が起こります。

一方、新規に HTML 形式のメッセージ作成ウィンドウを開いたときは、BODY 要素の DOM Node にはスタイル指定はありません。HTML 形式の性格上、画面内でユーザーがスタイルを指定するからだと考えられます。
しかし、Computed Style で見ると「white-space: normal;」という一行があります。この部分だけを見ると、HTML 形式のほうがホワイトスペースを省略してしまいそうですが、実際にはそのようなコピー動作にはなっていません。

このように、メッセージ作成ウィンドウにおける Thunderbird の内部的な white-space の初期値は異なりますが、これが、文字列をコピーした際にホワイトスペースの扱いの差となって現れてしまう現象と、どのように関係しているのかということです。

Thunderbird の設定を様ざまに変更して、メッセージ作成ウィンドウの内部定義がどう変わるのか、変わらないのかを調べていけば、もう少し細かいことが分かるかもしれませんが、当方のスキルではこのあたりまでが限界です。
コピーという動作に関していえば、Thunderbird のプログラム本体か、モジュールとしての JavaScript にも目を向ける必要があるのかもしれませんね。

Thunderbird 38.x 系で、メッセージ作成ウィンドウにおける[u]文字列のコピーで問題が起こる[/u]という話は、このフォーラムにも次のようなトピックが上がっています。
・Thunderbird 38.0.1 におけるコピー&ペーストの動作について
http://forums.mozillazine.jp/viewtopic.php?t=15480

具体的な症状は異なりますが、本件もメッセージ作成ウィンドウにおける文字列のコピーの不正常な動作という点で、なにかしら関連する原因があるのかもしれません。なお、この件も Thunderbir 31.x 系では発生していませんでした。

[b](*)[/b]
上記トピックで回避策となっている mail.compose.wrap_to_window_width = true の状態だと、プレーンテキスト形式のメッセージ作成ウィンドウの引用文であっても、連続したホワイトスペースはひとつにまとめられてしまいます。
mail.compose.wrap_to_window_width = false（初期値）の場合、引用文は SPAN 要素として扱われますが、mail.compose.wrap_to_window_width = true の場合は地の文と同じ BODY 直下の要素として扱われますので、その違いが引用文をコピーした結果の違いとなって現れているのかもしれません。

以上、表面をなぞったばかりの話で失礼しました。
プログラムの中身を読み解くスキルがないことは自覚していますので、まったく見当外れのことを書いていたらスルーしてください。

[quote="john"]# 送信時にプレーンテキストで送るとは言え、プレーンテキスト用テキストをHTML形式で編集するのは気持ち悪いですが仕方ない。[/quote]
Thunderbirdのテキスト形式でのメール編集は、内部的にはHTMLでの編集であって、"white-space: pre-wrap "を指定してあって、テキスト入力以外は一切させないだけ。
今回の現象は、HTML形式で編集している時だと"white-space: pre"を使っているので問題が起こらなくて済んだということ。
Delivery Format=Plain Text Onlyに変えればテキスト入力しかさせないから、もう一度HTMLモードに戻せる、ということを除けば、テキスト形式での編集とほとんど変わらない。

メール作成中の背景色を暗くしてメール作成中の画面を見やすくしたい時などには便利です。
テキスト形式での編集だと、メール作成中の背景色の設定などはないですから。
章のタイトルは<H3>、章の中身は<PRE>とか<P>で作って、メール作成中の視認性を良くする、ということもできます。
実際に、テキスト形式での編集でも文字色とか背景色とかある部分の色とかフォントとかを、設定で指定できるようにして欲しい、というバグが開かれていて、
理由を聞くと、常にテキスト形式で送りたくて、でもメール作成中の画面の視認性を良くしたい、ということでした。
もっとも、Delivery Format=Plain Text Onlyに変えるのを忘れると、HTMLで送られて泣くことになっちゃいますけど。
要は、考えようと、慣れ。

[追記]
"Custom Buttons"というアドオンでツールバーボタンを作り、簡単なボタンのスクリプトでDelivery Formatをクリック一発で切り替え、ができると、テキスト派にとって便利そうです。
コンポーザーのツールバーに追加させる、というツールバーボタンも要りそうですけどね。
でも、テキストモードだったら"white-space: pre"に変えてしまう、という方がいいかな。
[/追記おわり]

[quote="WADA"]
もろに「[url=https://bugzilla.mozilla.org/show_bug.cgi?id=1193153]Bug 1193153 - Copy/paste from a plain text editor loses white-space (multiple spaces/blanks, tabs, newlines) since plain text editor uses "white-space: pre-wrap"[/url]」の現象ですね。

Shift+Composeでコンポーザーを立ちあげてHTML形式で編集してDelivery Format=Plain Text Onlyを指定(オプション/送信形式、かな)、で逃げるのが楽かな。
[/quote]


既知のバグだったのですね。
マイルストーンが空欄ですが、一応アサインはされている様なので対応を待ちます。

HTML形式で作成するのが一番手っ取り早いようですのでそうします。
# 送信時にプレーンテキストで送るとは言え、プレーンテキスト用テキストをHTML形式で編集するのは気持ち悪いですが仕方ない。


WADAさんありがとうございました。

[quote="john"]■現象
メール作成画面で連続する半角スペースをコピーすると、半角スペースが１つとして認識される。

■再現
テキスト形式のメール作成画面を開く。
「ペースト」ではなく「コピー」が上手くいかないようです

メールの表示画面でコピーすると再現しません。
HTML形式の作成画面でコピーすると再現しません。
[/quote]
もろに「[url=https://bugzilla.mozilla.org/show_bug.cgi?id=1193153]Bug 1193153 - Copy/paste from a plain text editor loses white-space (multiple spaces/blanks, tabs, newlines) since plain text editor uses "white-space: pre-wrap"[/url]」の現象ですね。

Shift+Composeでコンポーザーを立ちあげてHTML形式で編集してDelivery Format=Plain Text Onlyを指定(オプション/送信形式、かな)、で逃げるのが楽かな。

HTML形式で編集してDelivery Format=Auto-Detectのままでも、Body TextかPREに文字だけ、という場合には、宛先がアドレス帳でHTMLを指定していないコンタクトならば、黙って勝手にtext/plainで送ってくれるから、これを利用するという手もあり。
「後で送信」で確認してみるといいでしょう。

更に補足します。
連続した半角スペースを使う表現は過去あまりやっていなかったので、
昔からこの［仕様／バグ］だったかは認識していません。
最初のポストでは最近発生したかのような記載をしていますが、語弊のある表現でした。すみません。

なお、情報を検索してみましたが、別のトピックが沢山引っかかってしまい同様の現象を発見できませんでした。

38.2.0（もしくはその１つ前）にアップデートしてからだと思うのですが、
メール作成画面での半角スペースのコピーで意図しない挙動になってしまいます。

■現象
メール作成画面で連続する半角スペースをコピーすると、半角スペースが１つとして認識される。
これを回避できないでしょうか。


■再現
こちらでは次の手順で再現しています。

[list=1]
[*]アカウント設定 > 編集とアドレス入力 > 編集
[*]「HTML形式でメッセージを編集する」をオフにする。
[*]テキスト形式のメール作成画面を開く。
[*]作成画面上の“半角スペースが連続したテキスト”をコピーする。　→例「　　hoge　　　 fuga」
# 例示のテキストでは全角スペースになっていますので、半角スペースに置き換えてください。[/list]

４でコピーしたテキストの内、半角スペースが１つに省略されてしまいます。　 →例「 hoge fuga」
■補足
[list]
[*]「ペースト」ではなく「コピー」が上手くいかないようです。[list]
[*][コピー元]　　[ペースト先]　 [再現]
作成画面　→　作成画面　 ＝　する
作成画面　→　メモ帳　　 ＝　する
メモ帳　　→　作成画面　 ＝　しない
メモ帳　　→　メモ帳　　 ＝　しない[/list]
[*]セーフモードでも上記手順で再現します。
[*]メールの表示画面でコピーすると再現しません。
[*]HTML形式の作成画面でコピーすると再現しません。
[*]全角スペースのコピーでは再現しません。[/list]

現在の環境：
Thunderbird 38.3.0 / Windows7 pro 32bit
（→少なくとも38.2.0ではこの問題が発生していた）


宜しくお願いします。