Open
Bug 210445
Opened 21 years ago
Updated 2 years ago
Cannot launch a compose window via "mozilla.exe -compose attachment=file://somefile" if the attachment contains chinese characters in the path
Categories
(MailNews Core :: Attachments, defect)
Tracking
(Not tracked)
NEW
People
(Reporter: joey.shen, Unassigned)
References
Details
(Keywords: intl)
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.
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•21 years ago
|
||
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: intl
OS: Windows XP → Windows 2000
Summary: Mozilla 1.4 for Windows cannot launch the second compose window via "mozilla.exe -compose attachment=file://somefile" if the attachment contains chinese characters in the path → Cannot launch a compose window via "mozilla.exe -compose attachment=file://somefile" if the attachment contains chinese characters in the path
Comment 3•20 years ago
|
||
*** Bug 254869 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: MailNews → Core
Comment 4•18 years ago
|
||
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•17 years ago
|
||
sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
Assignee | ||
Updated•16 years ago
|
Product: Core → MailNews Core
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•