288424 - filename of attachment is truncated at the first # when using mozilla-xremote-client

Status: RESOLVED FIXED

(Thunderbird :: General, enhancement)

Description

[Roberto Salomon]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050223 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050223 Firefox/1.0.1

This bug complements bug 243504 since it seems that more than one codepath is
involved in the problem.

I've been facing this problem for a while now. It is still present on the latest
Thunderbird trunk builds. I have developed a series of scripts that send files
to several translators in the pt-BR version of OpenOffice.org. At one point, one
of the scripts calls Thunderbird's mozilla-xremote-client, as in the following
example:

<path to thunderbird>/mozilla-xremote-client -a thunderbird
"xfeDoCommand(composeMessage,to=[e-mail],subject=Another,attachment=file:///<path>/test#file#1.txt)"

This results in a new message window being shown with the fields to and subject
correctly filled but with the attachment pane only showing test. When attempting
to send the mail, Thunderbird issues the following message:

Sending of message failed.
There was an error attaching test. Please check if you have access to the file.

Manually deleting the attachment from the pane and using the attachment button
or the File-Attach-File(s) menu results in the file name being correctly
displayed in the attachment pane, confirming that bug 243504 was solved.

When placing the mouse pointer over the attachment name on the first case (sent
via script), the hover shows the file name as file:///<path>/test#file#1.txt
However, when adding the attachment through the GUI, the hover shows the file
name as file:///<path>/test%23file%231.txt

It seems that two different code paths are being used to parse an attached file
name.

Reproducible: Always

Steps to Reproduce:
1. Create a file with a name including the # character in it: eg test#file#1.txt
2. run <path to thunderbird>/mozilla-xremote-client -a thunderbird
"xfeDoCommand(composeMessage,to=[e-mail],subject=Another,attachment=file:///<path>/test#file#1)"
3. When the message window is displayed, attempt to send the message

Actual Results:  
Thunderbird displays the following message:

Sending of message failed.
There was an error attaching test. Please check if you have access to the file.

Expected Results:  
The message be sent with the file test#file#1.txt attached to it.

Comment 1

[Magnus Melin [:mkmelin]]

If I use %23 instead of # the everything works fine (except you left out the
.txt in steps to reproduce). 

I too see the problem if # is used. I guess the special meaning of # is not
getting escaped somewhere...

Comment 2

[Roberto Salomon]

Using %23 only worked when enclosing the file:/// url in single quotes as in:

<path to thunderbird>/mozilla-xremote-client -a thunderbird
"xfeDoCommand(composeMessage,to=[e-mail],subject=Another,attachment='file:///<path>/test#file#1.txt')"

Otherwise it will fail as in my description. It really seems that the #
character is not being escaped when using the mozilla-xremote-client app.

Comment 3

[Robert Cluff]

I've had the same problem on all Tbird releases from 0.8 to 1.0.  I had one long
server path with # in one subdirectory name.  Thunderbird truncates the name of
any file attachment below that point at the # in the path, so the actual
filename and its extension do not appear - only the characters in the
subdirectory name that precede the #.  

100% reproducible.  Same behavior if I drag and drop the file or use File Attach
and drill down to the file.  Deleted special character from the subdirectory
name and subsequent attachments appear normal with full filename.ext

Comment 4

[Magnus Melin [:mkmelin]]

Robert: thats bug 243504, which was fixed after 1.0. This bug is only about the
case where mozilla-xremote-client is used with a file/dir name containing #. 

Comment 5

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 6

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.

Comment 7

[Magnus Melin [:mkmelin]]

-> new
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b5) Gecko/20051019 Thunderbird/1.5
ID:2005101906

Comment 8

[Roberto Salomon]

Tested on 1.6a1 (build 20051116) and the problem is still there.

Comment 9

[Roberto Salomon]

Tested on 1.5rc2. Command line works if "#" character is replaced by escape sequence %23. Drag and drop doesn't.

Thunderbird 1.5 rc2
SuSE Linux 10.0

Comment 10

[team]

I am nearly sure that the patch on bug 384160 fix this issue. It's the same problem, the uri is not correctly encoded.

Comment 11

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #10)
> I am nearly sure that the patch on bug 384160 fix this issue. It's the same
> problem, the uri is not correctly encoded.

To [e-mail]:
String of "file://..." in attachment="file://..." is file: URI format and is considered to be a URI defined by RFC as attachment="www.mozilla.org".
So escaping should be done when compose URI string.
I agree with you on that your patch is effective and convenient for users. 
But, if your patch will be landed, I think above consensus on "URI defined by RFC" will be broken, and will cause confusions by not only users but also developers.
I think proper way is next. What do you think?
 1. Introduce new sheme of command line parameter for local file
    (any local rule can be used. no need to care on RFC)
    such as attachment=local_file:'file name.xxx',
    and covert to properly escaped file: URI by your logic.
 2. Use new scheme when Drag&Drop.

Comment 12

[team]

-> WADA : 
  I am more for the first solution. Even the developpers need a convenient solution. Not anyone has a uri encoder under the hand, and I don't speak about one which respects strictly the RFC. But yes, this patch is mainly for integrators and   integration in the Desktop (linux Desktop, of course ;)).
  But if this solution is choosen, then you need to add some warnings or some stoppers to the rfc call (file:///...filename_with_accent.txt). It's really, really, really surprising to see the attachment, to be able to open it but not be able to send it. 

Thanks for your comment,

Comment 14

[Biju]

what ever may be the solution after fix please test and ensure following works fine
 thunderbird -compose attachment=http://www.mozilla.org/developer/#builds


(In reply to comment #11)
> I think proper way is next. What do you think?
>  1. Introduce new sheme of command line parameter for local file
>     (any local rule can be used. no need to care on RFC)
>     such as attachment=local_file:'file name.xxx',
>     and covert to properly escaped file: URI by your logic.

what about reducing "attachment=local_file:" 
to one new parameter name like  "local_attachment="
 thunderbird -compose local_attachment='/mydir/file name.xxx'

also there should be a way to attach multiple files/url

Comment 15

[Noèl Köthe]

from KDE action we use:

thunderbird -compose "attachment='file://%f'"

which results in the process:
$ cat /proc/25826/cmdline
/bin/sh/usr/bin/icedove-composeattachment='file:///tmp/test#file.txt'

so the shell doesn't cut the file.

Comment 16

[Magnus Melin [:mkmelin]]

This bug is in part invalid, if you use a file:// url the # must be escaped. 

However, the workaround is to use the file name directly instead. That landed yesterday in bug 384160.

With todays trunk build, both of these work.
 ./thunderbird -compose "attachment=/home/magnus/tmp/test#2.png"

 ./thunderbird -remote "xfeDoCommand(composeMessage,to=[e-mail],subject=test,attachment=/home/magnus/tmp/test#2.png)"

->FIXED by bug 384160.