241291 - Links to files with parentheses in the filenames don't work

Status: RESOLVED INVALID

(MailNews Core :: Composition, defect)

Description

[Yossi David]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040417
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040417

1. Links in email messages to local or network files that have parentheses in
the filenames don't work properly. When the message is received, the link
extends only as far as the closing parenthesis, rendering the link inactive.

2. In addition, the received message contains a second link of the form
cid:[e-mail]. Clicking ion this link opens a blank
browser window.

3. Links have %20 inserted wherever there's a space in the file name. This makes
it more difficult for recipients to read the file path and name if they need to
browse manually when the link doesn't work.

4. Link Text comes through as plain text in the received message, with no link
at all. This is true for URLs as well.

I realize that I am using a nightly build that is expected to be buggy, but I
experienced similar problems using earlier released versions, though I didn't
spend as much time characterizing them (i.e. I don't know if the problems were
as extensive).

5. Considering the severity of the problems I'm encountering, I'm wondering if I
might not have a local problem that is not directly Mozilla related. Is there
anything I should check in my Mozilla or Windows settings?

6. All in all, inserting links in email messages worked much better in Netscape
4.7x (I never tried NS 6). NS also had context menu options to insert a link and
to browse to a link in the Compose window to test that link is functional. these
would be welcome additions to Mozilla.

Reproducible: Always
Steps to Reproduce:
1. Open a Compose window
2. Select Insert>Link
3. Leave the Link Text field blank
4. Browse to a local or network file in the Link Location field. Select a file
that has parentheses in the file name.
5. Send the mail
6. Repeat the above process, but this time enter some text in the Link Text field

Actual Results:  
In the received mail the link doesn't work. The link extends only as far as the
last character before the closing parenthesis. Also, and spaces in the
path/filename are replaced by "%20" (also in Compose window).

Adjacent to the file link is a second link of the form cid:part1. ... Clicking
on the fields opens a blank browser window.

In the second test (with Link Text) there is no link to the file at all. The
Link Text shows up as plain text, and the only link is the cid:part1. .. This
also happens with links to URLs that use Link Text.

Expected Results:  
1. Received mail should have functional links.
2. Spaces should be spaces and not "%20"
3. Link text should work the same as filenames and URLs
4. there should be no cid:part1. ... links.

Comment 1

[Mike Cowperthwaite]

(In reply to comment #0)
I'm assuming that what is happening here is: You compose a message in HTML, and 
drag a file into the message body pane.  Appears as a link with "file://" text.  
You click Send and the message goes off (without any prompt about whether to 
convert the HTML file to plain text).  The message is actually sent in plain 
text (item 4).  Link is displayed in two forms, neither of which opens the file 
(items 1 and 2).

> 1. Links in email messages to local or network files that have parentheses in
> the filenames don't work properly. When the message is received, the link
> extends only as far as the closing parenthesis, rendering the link inactive.

The plain-text renderer's recognition of the "file://" URL stops at the 
parenthesis.  As it turns out, parentheses are not legal characters in URLs. See 
bug 133016.  This is unlikely to change except to make the recognition more 
selective, rather than less.

Also even if the file:// URL is correctly recognized across a completely legal 
name for a file that actually exists in the local filesystem, clicking it 
doesn't open that file.  See bug 135830, and also bug 241573.

Dropping the file into the body should not insert text in the form of a file:// 
URL; I have opened bug 241572 about this issue.


> 2. In addition, the received message contains a second link of the form
> cid:[e-mail].

This is because the file is included in the message as a separate MIME part, 
similar to an attachment.  The "cid:" link is how URLs are constructed to point 
to items inside a mail message.

> Clicking on this link opens a blank browser window.

If the message is converted to plain text on sending (see item 4), the file is 
stripped out.  This is a bad thing; see bug 187064, also bug 113435 comment 10 
et seq.  The particular behavior of stripping out content on converting to 
plaint text may warrant its own bug.


> 3. Links have %20 inserted wherever there's a space in the file name. This
> makes it more difficult for recipients to read the file path and name if they
> need to browse manually when the link doesn't work.

This is true, and it is unnecessary to escape the spaces at this point, since 
(a) it's actually text and (b) the link is inoperative anyway.  I've made note 
of this in bug 241572.


> 4. Link Text comes through as plain text in the received message, with no link
> at all. This is true for URLs as well.

Possibly, the recipient is suppressing HTML rendering, using the menu
  View | Message Body As.   More likely, the message is being sent off as plain 
text -- Mozilla is aggressive about converting HTML messages to plain text. 
Again, see bug 187064.


> 5. Considering the severity of the problems I'm encountering, I'm wondering
> if I might not have a local problem that is not directly Mozilla related.
> Is there anything I should check in my Mozilla or Windows settings?

No, you're encountering known problems.


Fortunately for you, there is a workaround; several, in fact.
 - If all you want to do is send the path to the file (because it's on a shared 
network drive), then don't drag the file in, just send the path.  Yes, you'll 
have to type it in.
 - If you actually want to deliver a copy of the file, send it as an attachment, 
rather than inline in the message body.  You can either drag the file into the 
attachment panel, or you can use any of the means available to attach files 
(menu, toolbar, click on the attachment panel itself).
 - If you *really* need to put a link to the file inside the message body, use 
Insert|Link; use some readable, useful text instead of "file:// ..."  (This will 
still fail if your message is converted to plain text.)

Now: I'm marking this bug Invalid -- not because the symptoms you noted don't 
exist or should exist, but because it touches on too many items, all of which 
have preexisting bug reports.  Reopen if you feel it absolutely necessary, but 
the only other resolution is to dupe this bug to one of the others, and I am not 
sure which of the bugs is uppermost in your mind.  In my mind, the failure to 
send the file with the message is the major problem here, but your primary 
complaint seemed to be about the parenthesis in the filename causing the URL 
recognition to break -- which is pretty minor.

Comment 2

[Mike Cowperthwaite]

(In reply to comment #0)
> 2. In addition, the received message contains a second link of the form
> cid:[e-mail]. Clicking ion this link opens a blank
> browser window.

OK, found the report for this: bug 180997.

Comment 3

[Yossi David]

Thanks for the in-depth reply.

> I'm assuming that what is happening here is: You compose a message in HTML,
> and drag a file into the message body pane.  Appears as a link with "file://" 
> text.

The "broken" link is the same whether I drag the file into the message body pane
or if I use Insert>Link.

> Possibly, the recipient is suppressing HTML rendering, using the menu
>   View | Message Body As.   More likely, the message is being sent off as
> plain text -- Mozilla is aggressive about converting HTML messages to plain
> text. 

Must be the latter since the recipient is me and my setting is View>Message Body
As>Original HTML.

> - If you *really* need to put a link to the file inside the message body, use
> Insert|Link; use some readable, useful text instead of "file:// ..."  (This
> will still fail if your message is converted to plain text.)

Showing the link in the message is definitely the best of both worlds. If the
link works, that's most convenient for the recipient. If the link doesn't work,
at least the recipient can find the file on their own. In any event, it appears
that my link text is being converted to plain text so that option doesn't work
anyway. I understand that is covered by bug 187064 so I'll keep my eye on that
one to see when it get fixed.

Both kinds of file links worked fine in NS4.7x (I just tried again to make sure)
and I am curious why the performance is worse in Mozilla. Shouldn't every aspect
of Mozilla work at least as well as NS, if not better? 

Comment 4

[Mike Cowperthwaite]

(In reply to comment #3)
> The "broken" link is the same whether I drag the file into the message body
> pane or if I use Insert>Link.

That's true, so long as you leave the "link text" field blank in the Insert Link 
dialog.

> my link text is being converted to plain text so that option doesn't work
> anyway. I understand that is covered by bug 187064 so I'll keep my eye on that
> one to see when it get fixed.

Well, in yesterday's flurry of activity, 187064 was marked Invalid, so nothing's 
going to happen with it.  The one to watch is bug 180997.


> Showing the link in the message is definitely the best of both worlds. If the
> link works, that's most convenient for the recipient. If the link doesn't
> work, at least the recipient can find the file on their own.

You're ignoring the two basic issues here: (1) Links to locally-accessible files 
in most cases are not useful for email, because the recipient doesn't have 
access to the local filesystem. (2) file://  links in email are a security risk.

Therefore, if the file is on a local/LAN filesystem, it will be included the 
message.  (With the acknowledged bugs, noted in comment 1.)  Therefore, there is 
no link to the file where it originally exists.  The working part of the link -- 
the cid: URL -- points to the attached file (which currently is present only 
when the message is actually sent as HTML).

> Both kinds of file links worked fine in NS4.7x and I am curious why the
> performance is worse in Mozilla. Shouldn't every aspect of Mozilla work at
> least as well as NS, if not better? 

I argue that Mozilla *is* better, or trying to be better anyway.  It's a 
security issue to have the mail program open file:// links; therefore, Mozilla 
doesn't do that.

Comment 5

[Yossi David]

> You're ignoring the two basic issues here: (1) Links to locally-accessible
> files in most cases are not useful for email, because the recipient doesn't 
> have access to the local filesystem. (2) file://  links in email are a 
> security risk.
>
> Therefore, if the file is on a local/LAN filesystem, it will be included the 
> message.

1. In a corporate environment, the ability to send links to local files is
important. Sending files instead of links bloats everyones mailboxes. More
important is that it leads to multiple copies of the same files being located in
various places on the network (whether as distinct files or embedded in
messages). Since many files are changed from time tio time, this can also lead
to a serious configuration management problem. Someone may open a document that
was emailed to them a week ago, but the document may have changed by then. If
the mail includes a link only, there is no way to accidentally access the old
version of the file. So it seems that sending path/file names is the best I can
do so far. Active links just makes things more convenient for the recipient.

2. I'm not sure I understand the security issue. Since outside recipients can't
access the file, where's the risk in having an active link to a local file. The
recipient can see the path/file name, but that's about it. Where's the risk?
Anyway, they can see the same information if I send the path/file name in plain
text. What am I missing here.

3. I am leaving this bug marked as invalid, but I urge you consider regrading it
to an enhancement request, making the desired functionality a user selectable
configuration option. Of course this raises the parentheses problem again. And I
renew my request for the context menu options to insert a link and to browse to
the link target (as in NS 4.7x).

Comment 6

[Mike Cowperthwaite]

(In reply to comment #5)
> 1. In a corporate environment, the ability to send links to local files is
> important. [...] So it seems that sending path/file names is the best I can
> do so far. Active links just makes things more convenient for the recipient.

Then, send the path in the tried-and-true Windows format.  If active links are 
that desirable, configure a webserver and serve the files up via http: -- mail 
handles those URLs with no problem.

> 2. I'm not sure I understand the security issue. What am I missing here.

The issue is not about the transmitted file; it's about a message with a link to 
a file on the recipient's filesystem.  While there is no straightforward means 
of accessing that file's contents from without, there may be some devisable 
means to do so (i.e. javascript running in the message).  By turning off the 
file: accessibility from mail, those sorts of exploits are prevented, or at 
least made that much more difficult.

> 3. I am leaving this bug marked as invalid, but I urge you consider regrading
> it to an enhancement request, making the desired functionality a user
> selectable configuration option.

I suggest you do some more in-depth reading -- like, of the half-dozen bugs I 
posted in comment 1 that related to your report. Is there some aspect to your 
report that is not covered by those?  If so, open a new bug (or bugs), focusing 
specifically on what it is you want changed.  This bug is invalid not because 
your facts were wrong, but because it was too broad.


> Of course this raises the parentheses problem again.

Well, parentheses are not legal characters for URLs.  That doesn't mean you 
can't serve the file up from a webserver, you just can't use a URL with the 
file's full name as it appears in the Windows directory.  It certainly sounded 
from Ben's comment in bug 133016 like the plain-text URL recognizer was going to 
become more conservative in that respect, not less.

> And I renew my request for the context menu options to insert a link

Search for a bug already open for that; if you can't find one, open a new one.

> and to browse to the link target

If you mean "support file: URLs in mail" see bug 135830, to which I've already 
pointed.  Links already have a context menu for Open.