144188 - Type TAB in mail -> Recipient sees space or newline (line break)

Status: RESOLVED FIXED

(Core :: DOM: Serializers, defect)

Description

[guanxi]

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
---------------------------

Comment 1

[guanxi]

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

Comment 2

[Shotaro Kamio]

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.

Comment 3

[Shotaro Kamio]

Attachment: 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.)

Comment 4

[Shotaro Kamio]

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

Comment 5

[Shotaro Kamio]

changed the summary to have some good keywords for searching.

Comment 6

[guanxi]

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 
---------------------------

Comment 7

[Shotaro Kamio]

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

Comment 8

[Kelley Cook]

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.

Comment 9

[Tal Cohen]

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

Comment 10

[kinmoz]

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

Comment 11

[Akkana Peck]

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.

Comment 12

[Shotaro Kamio]

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

Comment 13

[Jonathan Larmour]

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.

Comment 14

[guanxi]

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.

Comment 15

[Mike Cowperthwaite]

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