Using jun02 builds: 1999060208 NT 4.0 1999060208 Linux rh5.2 1999060209 MacOS 8.51 A mail or news message sent by seamonkey will display truncated to the recipient when there is more than one space between words. The display in the compose window appears fine, but received message is truncated after the extra space. 1. Launch to messenger. 2. New Msg. Address it. Type a sentence with the first few words having only one space in between the words and then put two spaces in between the next two words. Note at this point the compose window displays as you typed it. 3. Send the message, then Get Messages and display that message. Result: Words appearing after the extra space are truncated.

This will be particularly annoying to most users as the proper way to separate two sentences in a paragraph is to do so with two spaces. So, only the first sentence will be transmitted in that case.

Should be fixed for M7 since this is technically a "data loss" since the user is unaware that parts of his/her message is not being sent. I wonder if mscott's smtptest.exe shows this problem. If so, it would be scott's area.

This problem occurs only in HTML mode. The data messenger receive from Ender is already truncated! I reassign this bug to Ender team

cc: sujay. Sujay - do you have problems with this in the editor where you lose data after typing two spaces in a row? Perhaps after a save/save as?

just tried it in the editor on 6/2 Windows build....no problems there..no data/text loss or truncation after inserting more than 1 space or Save/SaveAs.

Akkana, could you do the initial investigation from the editor's side? cc'd simon in case he has any insights.

This this problem new in the 6/2 build, or does it happen in older builds?

Appears to have started in 6/01 m7. Tested m6 and the problem didn't happen.

Peter mock tells me in the 6/01 m6 mac build, if he enters several spaces in between words (say 5), they'll get stripped down to a single space. But the words all are displayed in the received message.

This problem is caused by the nsString2 changeover. Specifically, the problem occurs when converting between 1-byte strings containing non-breaking spaces (decimal 160) and 2-byte strings. In CopyChars1To2(), a signed char is used as an index into the kIsoLatin1ToUCS2 table. When copying a high-ascii char, you'll get a negative offset, so be reading off the start of the table. The fix is to change this to use unsigned chars. It's also interesting that all 1-byte strings are assumed to be ISO-8859-1 (Latin-1). This implicit charset conversion may cause surprises on conversion. How do we know that all 1-byte strings are Latin1?

This problem has caused much grief in I18n testing of Latin 1 accented characters. Lisa, Stacey, Laurel, could you possibly test with the 3 additional characters when you do "send mail" on Latin 1? These will help sniff out potential international problems early and avoid lost time. NBSP -- just pressing the space bar multiple times as described in this report will input this 8-bit character for now until   is used by Ender. ™ -- Trademark -- ALT + NumPad 0153 (Not working on 5.0. So use copy/paste) © -- Copyright -- ALT + NumPad 0169 (this combo is now working.) Inputting these and how they are received will help all of us greatly. Thanks!

Wait up! Before you go down an extensive testing road today, note that a fix for this bug has been checked in by rickg, and that tague has yet to fix bug 6208. Until tague checks in a fix for 6208, then all non-ASCII text input will be messed up.

This bug has been fixed by rickg, and I'm marking it so on his behalf. The symptoms of this bug that I was seeing have gone in my current build.

My comments are not menat for this specific bug though they certainly can be used for verification of this one. What I wanted was for the Mail/News QA to add the 3 characters to the testing data generally for future testing.

OK. I looked at Bug 6208. There is some specific conditions under which the problem in Bug 6208 occurs. So no non-ASCII input is still possible but one needs to avoid certain actions. If interested, please read Bug 6208.

I use 4.61 to compose a mail using the 3 characters as mentioned by momoi dated 6/3/99. And then view the message using 5.0 linux and mac. I cannot see the trademark character on Linux but I can see on the Mac.

<Fenella, what momoi mentions is a suggestion. Check w/ him and file separate bugs if necessary. This bug has nothing to do with viewing messages. Thanks.>

I agree with lchiang. If extra spaces don't cause this problem, then most likely other high-bit characters will not be a problem. In this case, NBSP being a high-bit character happened to have caused this problem. But any other high-bit character would have caused a similar problem, which is what International QAs reported. For Linux problem you saw of the trademark symbol, please files a separate bug. It is most likely a Unix font issue and not related to this bug.

Not fixed -- same results using 1999060411 Mac OS 8.51, 1999060410 linux rh5.2 and 1999060408 NT 4.0.

Since this bug has been sidetracked several times, please explain what still does not work. Are you saying that the mail truncate problem still occurs?

Mail is truncated. I reopened this bug because the same truncation happens as originally reported.

Back to Simon for further investigation. Thanks Simon!

OK, CopyChars1To2() still has problems. Specifically: const char *first; *to=(PRUnichar)(*first); fails if *first > 127. Why? Because it's a signed char, and if its high bit is set, *to ends up containing a large -ve number. So the fix is this: void CopyChars1To2(char* aDest,PRInt32 anDestOffset,const char* aSource,PRUint32 anOffset,PRUint32 aCount) { PRUnichar* theDest=(PRUnichar*)aDest; PRUnichar* to = theDest+anDestOffset; const unsigned char* first= (unsigned char *)aSource+anOffset; const unsigned char* last = first+aCount; //now loop over characters, shifting them left... while(first<last) { *to=(PRUnichar)(*first); to++; first++; } } Reassigning to rickg.

If anyone cares, there's already a bug, 5383, on the trademark entity not displaying on Unix.

I checked in the above changes (using unsigned chars). Marking fixed.

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

Note to bug fix verifier: Need to verify duplicate bug http://bugzilla.mozilla.org/show_bug.cgi?id=7497 which has lots of others bugs marked a duplicate of it. Many cases to verify.

update: using builds 1999060808 on Win,Linux & Mac is fixed for the original scenario. A new bug will be logged for Laurel's commments on 6/2 from Peter about more the multiple spaces get stripped down to 1 space after message is sent, received and opened.

New bug for multiple spaces being reduced to one space is (7800). It also happens on Editor so the bug was assigned to akkana and the Browser|Editor product.