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? ;-)
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.
*** Bug 254869 has been marked as a duplicate of this bug. ***
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.
sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.
Filter on "Nobody_NScomTLD_20080620"