210445 - Cannot launch a compose window via "mozilla.exe -compose attachment=file://somefile" if the attachment contains chinese characters in the path

Status: NEW

(MailNews Core :: Attachments, defect)

Description

[Joe]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529

In general conditions, users can launch multiple message compose windows by
repeating mozilla -compose commandline in the commandline shell of Windows.
However, in the condition that there is already a running instance of Mozilla
(not necessarily be message compose, could also be the browser window and
others), while at the same time, the attachment path contains chinese
characters(I'm not sure whether it works fine with other none ASCII characters),
the compose window can not be launched. 

Reproducible: Always

Steps to Reproduce:
1.run the following commandline line in the Windows commandline shell
mozilla -compose attachment=file://<a file path contains Chinese characters>
2.run the commandline in step 1 again
3.

Actual Results:  
If there hasn't been a running instance of mozilla currently, step 1 would
launch a Message compose window with the chinese path file in the attachment field.
Don't close the compose window launched by step 1 and do step 2, it fails to
launch the second compose window

Expected Results:  
step 2 could launch a second compose window with the chinese path file in the
attachment field.

As I know for Linux, mozilla would use -remote to open new windows shared with
profile with the currently running instance of Mozilla, I'm not sure how mozilla
implement this for Windows, and why the commandline behave differently.

Comment 1

[Joe]

It's been a long time since the bug was filed, why not still unconfirmed? was it
because of what AOL has done to netscape and mozilla.org? ;-)

Comment 2

[Mike Cowperthwaite]

Confirming; I see this with
  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040422

See also bug 139114.

Comment 3

[Mike Cowperthwaite]

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

Comment 4

[Mike Cowperthwaite]

I'm not sure if this is a workaround, or the way that this has to work:  If you use the browser to open the file in question, it will show a URL with the characters properly escaped (as raw non-ASCII is not allowed in a URL).  If you use that URL in the compose argument, it works as expected.

Example: I have a file on my disk named:  ﺺﻒﻖﻧ.png (Arabic, and I think those characters are shown here LTR while the displayed RTL).  This converts to the URL:
  file:///<path>/%EF%BA%BA%EF%BB%92%EF%BB%96%EF%BB%A7.png
And if I feed that URL to the -compose switch, the filename appears as expected in the compose window's attachment panel.

See bug 169388 for the general problem of non-ASCII in URLs.  While browsers can use IDN to re-encode the character string properly, that doesn't apply to local files.

However, even with the corrected URL, the file still cannot actually be attached, at least under Windows: this is bug 334280.

Comment 5

[(not reading, please use [e-mail] instead)]

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.

Comment 6

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"