Closed Bug 9762 Opened 25 years ago Closed 25 years ago

Space at the end of headers in 5.0 sent HTML msgs get displayed as a square or vertical bar

Categories

(MailNews Core :: Internationalization, defect, P3)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: momoi, Assigned: nhottanscp)

References

Details

Attachments

(2 files)

** Observed with 7/12/99 Win32 build ** ** This bug was split from Bug 8128 since that bug dealt only with strange character problem in message body. ** There seems to be a strange problem with headers under Latin 1 HTML mail which leads to an insertion of a square box at the end of the header string. Try the following steps 1. Compose HTML Latin 1 mail with 5.0. 2. In the header and body, input the following strings. Bonjour internationê<SP> where is says <SP>, insert a single ASCII space. 3. Send it and look at it with 4.x client. You will see that there is what seems to be a vertical bar at the end of thread pane headers and a blank square in message pane headers. Notes: A. This looks like an attempt to encode &nbsp; . B. The length of the string was a critical factor. I could not reproduce this problem when I had more characters in the strings, e.g. Bonjour internationnê (one more "n" in the 2nd string) did not cause this problem. C. Other strings I tried were: Bênjournë<SP>, Bënjourê<SP>, Bonjour Internationalê<SP>, etc. None of them produced this problem. So there is something special about the number of characters in "Bonjour internationê<SP>". D. This square does not show up in message body when the same string is input there. E. I did not see this problem when I tried the same strings under plain text mail.
Setting to M9. ducarroz@netscape.com to cc. >E. I did not see this problem when I tried the same strings > under plain text mail. Jean-Francois, do we treat subject field differntly between html and plain message?
Status: NEW → ASSIGNED
Target Milestone: M9
Target Milestone: M9 → M10
I am not able to fix this in M9. Probably better to verify this once gfx text widget lands. Move mile stont to M10.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
Using my local build (pulled 8/10), I cannot see this problem.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
** Checked with 9/16/99 Win32 build ** This problem still exists and it has an unwanted consequence. A message with this problem does not display the body at all with an error message saying that: XML Error in file 'imap://kaze.mcom.com:143/fetch>UID>/Inbox>10', Line Number: 2 4, Col Number: 20, Description: not well-formed Source Line: Bonj�Er opposition�E</html:td> 4.7 has no problem showing this message but subject header does contain a square box at the end of the header line in the source: Subject: =?ISO-8859-1?Q?Bonj=ECur=20opposition=EA?= In any case this is not a cosmetic problem any more since the message does not display when you see what looks like a right-end JPN quote symbol at the end of the line. One test msg I have also shows the left-end JPN quote like symbol. The test string is: Bonjour internationê<SP>
Target Milestone: M10 → M11
Sorry, the test string I used is: Bonjìur oppositionê<SP> instead.
Attached image binary dump of the header (deleted) —
I attached an image with hex dump of the header. The char which causes XML error is 0x02. I think this bug should be separated into two (send and view). I assume that an extra char is generated by Ender (does this always happen?). Viewing bug should go to XML.
For send, the most likely scenario is that the user types a string into the subject window and then somehow adds an ASCII space after it. This is not all that uncommon right after you have commited a Japanese string -- some people then immediately gets into the English typing mode by inserting the space for the next string. Another possibility is that you copy/paste a string and the copying includes a space at the end -- this is very common. I'll try to separate the bugs later today.
Status: REOPENED → ASSIGNED
QA Contact: momoi → msanz
Changed QA Contact to msanz since momoi is out for a week. Since the bug has not been separated as mentioned in the last comment, I assume that we going to focus on sending problem. I'll try to reproduce this.
Today's build both release and my local debug, message send doesn't seems to be working (after hit the "Send" button, the window is close but the message is not sent out).
Blocks: 11091
(target milestone is M11 or M12 - add to mail beta tracking bug)
Target Milestone: M11 → M12
By using today's release build (the last one), I was able to reproduce this but only once (20% occurrence so far). It's not happening with my debug build (it didn't happen before with debug build when the bug was opened in July). I need more reproducable cases. Also if this only happens with the specific case of the subject ending with a space then it's not very common. If this is really important to fix then probably easier to fix viewing side since that's always reproducable. I think I cannot resolve this for M11, changed to M12.
Is this bug still reproducible? How about linux? Adding ji to cc.
With 11/10/99 M11 candidate Win32 build, I can reproduce this problem about 20% of the time. The test string is: Bonjour internationê<SP> When this problem is observed under 4.7, Mozilla cannot display the message body at all. The thread pane header shows an extra little hook at the end.
Attached patch A patch file, reviewed by cata. (deleted) — Splinter Review
This is reproducable (with release build) when separators for encoded words (e.g. ",", ":", "(", ")", " ", etc.) comes at the end of the header string. I have a fix, and will check in after I tested more on my local build.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
QA Contact: msanz → momoi
Resolution: --- → FIXED
I checked in the fix on 11/17 (comi18n.cpp rev=1.51 not exactly the same as the attached diff). I tested win32 release build 11/18, "Bonjìur Oppositioné" + ' ', ',', '(', ')'. I didn't see the problem. So I think this is fixed, please verify.
Status: RESOLVED → VERIFIED
** Checked with 2/14/99 Win32 build (1999121408) ** I haven't been able to reproduce the original problem following the same procedures with the above and some recent builds. This problem seems to have been fixed. Marking it verified/fixed.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: