139114 - unable to attach a file with a name composed with international characters

Status: RESOLVED WORKSFORME

(MailNews Core :: Internationalization, defect)

Description

[Jean-Max Reymond]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417
BuildID:    2002041711

If you select a file with a name composed with international characters (like
qwerèty.txt), you have a box with the message: "file //tmp/qwer does not exist"

Reproducible: Always
Steps to Reproduce:
1.create a file /tmp/qwerèty.txt
2.compose a message
3.attach the file qwerèty.txt

Actual Results:  blocking message box 

Expected Results:  attach the file name /tmp/qwerèty.txt

Comment 1

[Boris 'pi' Piwinger]

WFM: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020419

pi

Comment 2

[Vadim Berezniker]

sounds like bug 97189

Comment 3

[ji]

Jean-Max, in which locale are you running mozilla? The file picker depends on
locale, for instance, if you are running mozilla in C locale, you won't be able
to pick up the file.

Comment 4

[Jean-Max Reymond]

yes, I am running in C locale and it works with export LANG=fr_FR
but, it is very strange to pick a file name and have this message even if the
LOCALE is not correct 

Comment 5

[ji]

We have bug 107941 filed for filename handling using unicode.

Comment 6

[Jean-Max Reymond]

not Unicode, just ASCII 8 bits

Comment 7

[ji]

If it supports unicode, it won't depend on the locale in which mozilla is running.

Comment 8

[nhottanscp]

Katakai san, do you know what we get for a platform charset for C locale, not
ISO-8859-1?

Comment 9

[Vadim Berezniker]

bug 97189, which I mentioned earlier is also describing a very similiar problem.
In that bug, when you save a file using the filepicker with a name containing
characters like 'è', then the filename gets truncated in the same way.
So if this bug is fixed, bug 97189 would probably then fixed too.

Comment 10

[Masaki Katakai]

Hi Hotta-san,

How are you?

I understand if we set "C", Mozilla uses 646=us-ascii
as the platform charset and it does define only ASCII.

Comment 11

[nhottanscp]

Katakai san,
Thank you, I am fine.

What if we change to ISO-8859-1? Would that cause problems?

Comment 12

[nhottanscp]

Katakai san, could you take care this?

If this is a feature then it can be marked as invalid or wontfix.

Comment 13

[Masaki Katakai]

I don't think any regression will happen when
we switch from us-ascii to iso-8859-1. If we consider
usability and compatibility between the existing environment,
we should use iso-8859-1 instead of us-ascii in C locale.

Anyway, I'll test.

Comment 14

[Masaki Katakai]

xpcom now uses mbtowcs() on Linux for conversion native to UCS2.
I tried this today and it works fine.

However, UNIX system such as Solaris, iconv() does not support
such range (non-ascii range) in 646 to UCS-2 converter. So
the problem is still exsisting and only changing us-ascuu ->
iso-8850-1 can not solve the issue. We have to hack xpcom/io.

I'll ask iconv() expert of Solaris why 646 to UCS-2 converter
does not support such range. Actually the specification does
not support such range but usually many users wants to use
the characters even when the application is running in C locale.

Comment 15

[Mike Cowperthwaite]

I just tried this in Linux (Ubuntu Dapper) with a file named with Chinese characters, in TB 1.5 and 3a1.  I think this is all working OK under Linux.
(Windows has some problems still; see bug 334280.)