Attachment filename in multi-byte language is corrupted, unable to open after received.

VERIFIED FIXED in mozilla1.0


18 years ago
11 years ago


(Reporter: ji, Assigned: rdayal)


({intl, regression})

Windows 2000
intl, regression
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [ADT1] [04/19])


(8 attachments)



18 years ago
Build: 10/03 MAPI comm. build
OS: Ja XP 

When the document's filename contains non-ASCII chars, I can't send it out using

Steps to reproduce:
1. Install Mozilla as the default mail application.
2. Bring up MS Word 
3. Enter something and save the document in a non-ASCII filename, like tëst or a
Japanese filename.
4. On MS Word, select File | Send To | Mail Recipient, mail account logon window
comes up. 
5. Logon with correct username and passwd, the MS Word pops up an error: Word
couldn't send mail because of MAPI failure: "Attachment not found", no mail
compose window comes up.

If I save the doc in an ASCII filename and follow the same scenario, I don't see
this error and I can get a mail compose window with the doc attached.

Comment 1

18 years ago
Added intl, nsbranch, nsenterprise keyword.
Keywords: intl, nsbranch, nsenterprise
QA Contact: trix → ji


18 years ago
Severity: normal → critical
Priority: -- → P1
Can we discuss this one at the PDT meeting today?

Comment 3

18 years ago
Same problem with 10/05 branch build.
I'm on Japanese XP with Office 2000 installed.

Comment 4

18 years ago
with 10-05 branch build i am able to send doc with Latin-1 file names only,
cyrillic name isn't working. Using WordPad on WinXP.

Comment 5

18 years ago
can you confirm which ones are working?

Comment 6

18 years ago
It depends on the platform.
On a US or latin-1 platform, it only works for ASCII or latin-1, but not working
for any other languages.
On a non latin-1 platform, like CJK, Cyrillic, it only works for ASCII, it
doesn't work for any other languages.
So it's totally broken for Central and Eastern European, CJK platforms.

Comment 7

18 years ago
CC'ed mscott. 

Comment 8

18 years ago
hey Rajiv, can you think of any spots in the mapi code where we may be casting
down from unicode to raw ascii causing us to lose / corrupt the file name?

Comment 9

18 years ago
thanks Xianglan; Tiantian, can you triage the nsbranch nomination?

Comment 10

18 years ago
reassign to Rajiv.
Assignee: tiantian → rdayal

Comment 11

18 years ago
There are two things that could be the reason :

1. MS Word / Wordpad is passing the Japenese filename but not setting the flag
MAPI_UNICODE (as defined by MAPI specs) which tells me that the filename is
unicode or ascii.

2. The nsIMsgCompFields expects the attachments in the form of a char *, a
string of file URLs delimited by commas. I use the nsIFile::GetURL function to
get the URL for the file which returns a char *. So maybe this conversion is
creating the problem. I talked to JF regarding this earlier asking if we should
take attachments as 'wstring' rather than char * but he mentioned that since
URLs are always in ascii the GetURL will take care of converting correctly and
it should work fine.

I will try and debug to see what is the FLAG and the filename when the
MAPISendMail function gets it from the MAPI app on a Japenese machine. Shirley
can i use ur japenese machine to do the debugging ? Meanwhile, JF and Scott can
u please give ur thoughts on 2 above.

Comment 12

18 years ago
Per rdayal's request, let me add that the problem is also reproducible
on Windows 2000 Professional Edition with the locale default set 
to Japanese. 

In addition,

1. Even if your word file has an ASCII name, if the first line of your
document contains Japanese, then that line will be used as the Subject
of the MAPI mail and that does not show correctly in Japanese/
This will be an additional problem, once you get past the final
name problem. --> see an image which will be attached below.

2. If you select the Japanese-name file in Windows Explorer and send it to
   "Mail Recipient" with the right-mouse click on the file, Netscape 6.2
   mail window does come up with the file attached and the file name correctly
   showing in the attachment window. However, the subject line
   which uses the filename does not show correctly in Japanese.

From 1 & 2, it seems that we are not dealing with the final names properly
via Word application but OK via the OS. In addition we are not dealing with
data passed to the subject line correctly in situation 1 or 2.

Comment 13

18 years ago
Created attachment 52308 [details]
An image of successful MAPI operation but with corrupt subject header (and therefore the window title).

Comment 14

18 years ago
The subject line should be identical to the first line
of the Word document, which is shown in Japanese in the 

Comment 15

18 years ago
Thanks Kat for checking this out. - rajiv.

Comment 16

18 years ago
Created attachment 52315 [details]
3 test files in .zip format.

Comment 17

18 years ago
The 3 files in the .zip attachment are as follows:

1. nihongo.doc (filename in ASCII, title in Japanese)
2. nihongo2.doc (filename in ASCII, title in ASCII)
3. "Nihongo".doc (filename in Japanese, title in Japanese)

File 1 should succeed but will have the subject line prolem
File 2 should succeed without a problem.
File 3 currently fails to go though simple MAPI. And will have
 a subject line problem once the 1st problem is resolved.


18 years ago
Keywords: nsbranch → nsbranch+
Marking ETA as 10.10 per PDT Simple MAPI Update.
Whiteboard: [ETA 10.10]

Comment 19

18 years ago
Created attachment 52774 [details]
Excel and PowerPoint test files format

Comment 20

18 years ago
Per discussio with rdayal,

1. Wordpad has no problem with word doc with JPN filename.
   Wordpad also does not pass the subject/title to MAPI.
  ** To test this, use the Word test files, open them with
     WordPad and try the MAPI function.
2. PPT file with JPN filename fails silently.
3. Excel file with JPN filename fails with an error dialog.

The above attachment contains, PPT and Excel test files -- one 
with a JPN name and the other with an ASCII name. (4 files in all.)

Comment 21

18 years ago
Created attachment 52796 [details]
A zip file containing 1 .doc file -- file name in JPN but title in ASCII.

Comment 22

18 years ago
marking nsenterprise-; will be reevaluated for nsenterprise in future release.

Keywords: nsenterprise-

Comment 23

18 years ago
rajiv, is there any evaluation on what it will take to fix this bug? It is
pretty serious

Comment 24

18 years ago
Hi, this is a must fix as listed in the meta bug for simple MAPI, bug 91702. 
Rajiv has been actively working on this. Target fix date is 10/10.

Comment 25

18 years ago
Please find below the patch to fix the problem of sending files with filenames
with non Ascii characters, eg : Japenese filenames.

Currently the code converts all the non unicode filenames passed to unicode if
the the MAPI_UNICODE flag is not set and then uses nsIFile Unicode operations
(for code optimization). However the MS Office apps send these non Ascii
filenames as char * and also DONOT set the MAPI_UNICODE flag as specified in the
MAPI specs.

I have modified the code such that it does not convert the filenames and uses
nsIFile non unicode operations if MAPI_UNICODE is not set and uses the nsIFile
unicode operations if MAPI_UNICODE is set.


Comment 26

18 years ago
Created attachment 52925 [details] [diff] [review]
patch with the fix for the problem in sending non Ascii filenames from Word, Excel and Powerpoint

Comment 27

18 years ago
Hi JF and Scott,
Can u please review and super review the patch attached above. 
- Rajiv.

Comment 28

18 years ago
Rajiv, does this patch address the subject problem that Kat mentioned?
Comment on attachment 52925 [details] [diff] [review]
patch with the fix for the problem in sending non Ascii filenames from Word, Excel and Powerpoint

Attachment #52925 - Flags: review+

Comment 30

18 years ago
Comment on attachment 52925 [details] [diff] [review]
patch with the fix for the problem in sending non Ascii filenames from Word, Excel and Powerpoint


Nice fix Rajiv! In the future can you send me email directly when you want a sr instead of just adding a comment in the bug? I'm more likely to see the email faster.
Attachment #52925 - Flags: superreview+

Comment 31

18 years ago
Created attachment 52985 [details] [diff] [review]
fix for the subject line in non-Ascii charset
pls check in the first patch = PDT+

PDT+ for the 2nd patch pending positive r/sr reviews.
Whiteboard: [ETA 10.10] → [ETA 10.10] [PDT+]

Comment 33

18 years ago
Comment on attachment 52985 [details] [diff] [review]
fix for the subject line in non-Ascii charset

r=nhotta, please fix the indent
Attachment #52985 - Flags: review+

Comment 34

18 years ago
Please find above the fix for the subject line not appearing correctly in the
Compose window if the subject line is in non-Ascii charset when sending from MS
Office apps. The code now finds the systems's currently set character set to do
the conversion for the subject (and also for the body) before sending the data
to nsIMsgCompose. 
Thanks very much Naoki for your help and the review. 
Scott, can u please sr the patch. thanks. - rajiv.

Comment 35

18 years ago
Comment on attachment 52985 [details] [diff] [review]
fix for the subject line in non-Ascii charset

Attachment #52985 - Flags: superreview+

Comment 36

18 years ago
checked into the 094 branch.
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 37

18 years ago
Verified with 10/11 0.9.4 build. It's fixed. 
Added vtrunk keyword.
Keywords: vtrunk

Comment 38

17 years ago
On 01/22 trunk build, the Ja document filename is not shown correctly on mail
compose window. Screenshot to follow.
Reopened the bug.
Keywords: nsbranch+, nsenterprise-, vtrunk → nsbeta1, regression
Resolution: FIXED → ---
Whiteboard: [ETA 10.10] [PDT+]

Comment 39

17 years ago
Created attachment 66162 [details]
A screenshot on a US W2K with default locale set to Japanese. The Ja document filename is corrupted.


17 years ago
Keywords: nsenterprise
did this ever get checked into the trunk? 

Comment 41

17 years ago
the patch (attachment id=52985) has landed on the trunk. The patch (attachment,
 id=52925) is not required as per the bug # 107697.


17 years ago
Keywords: nsbeta1 → nsbeta1+
Priority: P1 → P2


17 years ago
Target Milestone: --- → mozilla1.0

Comment 42

17 years ago
This could be related to bug # 128154.
Depends on: 128154

Comment 43

17 years ago
ADT needs info., Jeff Hooker, how many people are affected, and what is the
severity? Are you going after international enterprise customers?
Whiteboard: [ADT NEED INFO]

Comment 44

17 years ago
Please note that with this problem all the non-English spoken users won't be
able to send out MS documents with the filename in their own languages, and we
don't have this problem with NS6.2.1.

Comment 45

17 years ago
Latin1 case mentioned in the original report "tëst" works on my machine.
Used 04/09 commercial trunk on Windows 2000 US with MS Word 2002.

For Japanese, I had the problem, the Japanese file name got corrupted, like this
screen shot,
Subject was fine. 

I used test case,

Used 04/09 commercial trunk on Windows NT 4 JA with MS Word 2000 JA.

I had a problem after I sent a document in MS Word, I filed as bug 136448, that
is not specific to intl data.

Comment 46

17 years ago
The Japanese test case I mentioned in my last comment, although the file name
was corrupted, the message and the attached file were sent. I was able to open
the recieved attachment.


Comment 47

17 years ago
Yes, I'm also able to send it out. I should have modified the summary when
reopening the bug, sorry.
On my Simplified Chinese Windows XP with Simplified Chinese Office XP installed,
I'm unable to open the attachment with a corrupted Chinese filename after
received. After I click on Ok button on the download dialog with "Open using
Word" selected, MS Word doesn't launch. I don't have this problem with another
mail which has the exactly same attachment file but the attachment filename is
an ascii string.
Summary: Unable to send out when the document has a non-ASCII filename → Attachment filename in multi-byte language is corrupted, unable to open after received.

Comment 48

17 years ago
There have been changes in MAPI code to deal with changes in the Msg Compose
code for trunk landing, at one place comparision of non Unicode platform charset
strings is not done correctly. Please find a fix below.

Comment 49

17 years ago
Created attachment 79743 [details] [diff] [review]
fix for the updated trunk code

Comment 50

17 years ago
Comment on attachment 79743 [details] [diff] [review]
fix for the updated trunk code 

Attachment #79743 - Flags: review+

Comment 51

17 years ago
Comment on attachment 79743 [details] [diff] [review]
fix for the updated trunk code 

Attachment #79743 - Flags: superreview+

Comment 52

17 years ago
this looks like an [adt1] to me. The Office will default any document they
created to localized filename, so it is very common for non english user to use
non ascii file name. It looks like this bug will cause mapi useless outside us

Comment 53

17 years ago
Thank you very much Naoki and Scott for your r and sr.

Latest patch (id=79743), fix for the regression, checked in to the trunk.
Marking as fixed.

I agree with Frank, this definitly should go in to the branch in order for non
English users to use MAPI from MAPI client apps like MS Office, etc.
Nominating for 1.0 branch checkin.
Last Resolved: 18 years ago17 years ago
Keywords: adt1.0.0
Resolution: --- → FIXED
Pls check this into the trunk. Once ji has verified the fix, and that there are
no related regressions, we will consider it for the 1.0 branch.
Whiteboard: [ADT NEED INFO] → [ADT1] [Need ETA]

Comment 55

17 years ago
Verfied as fixed with 04/19 trunk build. The multi-byte attachment filename 
shows correctly and I can open it after received.
Ji - Pls mark as verified, when you have verified the fix on the trunk.

adt1.0.0+ (on ADT's behalf) approval for checking into the 1.0 branch. Pls check
this in today, then add the fixed1.0.0 keyword.
Keywords: adt1.0.0 → adt1.0.0+
Whiteboard: [ADT1] [Need ETA] → [ADT1] [04/19]
Attachment #52985 - Flags: approval+
Attachment #79743 - Flags: approval+ for branch checkin

Comment 58

17 years ago
has been checked into the branch yesterday, should be in today's build. Marked
fixed for the branch.
Keywords: fixed1.0.0

Comment 59

17 years ago
Verified as fixed on 04/29 branch build.
Keywords: fixed1.0.0 → verified1.0.0
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.