I'm rewriting a bug I reported, Bug 143763, to remove the part that is a dupe and otherwise clean up and shorten a very long report: If I type a <TAB> in Mail/News, the recipient sees something different: o Moz Mail/News substitutes a space for the first tab on each line and loses tab alignment o Moz | View | Message Source shows a new line (EOL?) for the first tab on each line. o Eudora Light 3.0.6 shows the same as Moz | View | Message Source. Reproducible: Always [You'll also see Bug 58712 when Moz displays TABs wrong in the Compose window] 1. In Mail/News, click the Compose button 2. In the frame for the e-mail body, type the following (skip the "quotes"): (A) "1Tab" <tab> "After 1Tab" <enter> <enter> (B) Repeat step (A), but type "1TabX" instead of "1Tab". (C) "2Tabs" <tab> <tab> "After 2Tabs" <enter> <enter> (D) Repeat step (C), but type "2TabsX" instead of '2Tabs". 3. E-mail the message to yourself. Here's what I receive: o MOZILLA appears to substitute a space for the first tab on each line; note the tab alignment is lost: --------------------------- 1Tab After 1Tab 1TabX After 1TabX 2Tabs After 2Tabs 2TabsX After 2TabsX --------------------------- o MOZILLA | VIEW | MESSAGE SOURCE and EUDORA LIGHT 3.0.6 appear to substitute an (EOL?) for the first tab in each line. Given that, tab alignment works: --------------------------- 1Tab After 1Tab 1TabX After 1TabX 2Tabs After 2Tabs 2TabsX After 2TabsX ---------------------------

*** Bug 143763 has been marked as a duplicate of this bug. ***

I confirmed on 1.0RC2/Linux and 2002051108/Linux. I found the cause of this bug. In nsPlainTextSerializer.cpp, which convert entered texts to plaintext and wraps, GetUnicharWidth() returns the width of the character. In the case of TAB, it returns -1. (It should be 8, I think.) http://lxr.mozilla.org/seamonkey/source/content/base/src/nsPlainTextSerializer.cpp#1224 1224 mCurrentLineWidth += GetUnicharStringWidth(aLineFragment, 1225 aLineFragmentLength); mCurrentLineWidth is unsigned integer. If we add -1 to it, it get wrongly larger value. So, text wrapped. ( TAB -> new line) I can show an ad hoc patch to fix this bug.

This patch fixes this bug. But I don't know this treatment is good or bad. (This patch contains some fixes to codes for debug purpose.)

*** Bug 125569 has been marked as a duplicate of this bug. ***

changed the summary to have some good keywords for searching.

The bug only seems to occur when composing in plain-text mode. When composing in html mode (Edit | Mail & Newsgroups Account Settings | Compose messages in HTML format), you get a different and probably unrelated bug: Each tab is replaced with 4 spaces; maybe it's intentional. It looks exactly the same to the sender and recipient: --------------------------- 1Tab After 1Tab 1TabX After 1TabX 2Tabs After 2Tabs 2TabsX After 2TabsX ---------------------------

mmm, this bug is deeply related to Bug 94475. And that has a patch. It seems to fix this bug also.

Just checked, It looks liked its been fixed in Mozilla 1.1a+ (2002062008) build. But it still occurrs in the 20020620 1.0.0 branch build.

Should the "Product" be "MailNews" for this bug?

This bug isn't in the editor and should be assigned to whoever owns the serializer code. Changing module to "DOM To Text Conversion"

If the fix for bug 94475 fixed this one, perhaps this should be marked as a dup? Looks like that fix was checked into the branch on 6/21.

This bug has been fixed on 1.0branch also. I confirmed on 2002-07-02-07-1.0 nightly/Linux. -> FIXED. (should be dup?)

Whether it's a regression or whatever, there is definitely a problem like this in moz 1.1 release/linux. Using the plain text editor, if you put TABs in the message body, they will display as tab stops for every 8 columns, e.g. as: yet another test of tabs vs spaces (I've substituted spaces in the above myself to be sure it displays correctly in this bug). Whereas when the message is sent, every tab is converted to 4 spaces every time. This is reflected in the stored message in the Sent folder too, e.g. yet another test of tabs vs spaces This is a pain because of pre-formatted ASCII tables, being cut'n'pasted in. The HTML editor is similar, except that it converts the TABs to 4 spaces immediately, so at least you can see how the message will appear when it gets sent, unlike the plain text editor. And the HTML editor does immediately do it as spaces, whereas the plaintext editor stores them as tabs (as proved by the moving the cursor over it). The choice of fixed vs. variable width makes no difference. This should preferably be fixed by making it use the TAB stops if TABs are to be converted to spaces at all. Otherwise at least it should do the same thing as the HTML editor so you will know what the formatting is like before the message is sent.

The original behavior described in this bug is fixed (I'm looking at Moz 1.3b (2003021008) on Win2K), so I'm Resolving it Fixed. I see an issue similar to Comment 13, on Win2K in my case, but that's a different bug.

*** Bug 165501 has been marked as a duplicate of this bug. ***