580253 - After detaching an attachment into a target folder whose name contains commas, X-Mozilla-External-Attachment-URL is truncated (causing file not found errors and non-responsiveness when user acts on the attachment)

Status: RESOLVED DUPLICATE of bug 350825

(MailNews Core :: Attachments, defect)

Description

[Christopher Schultz]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:2.0b1) Gecko/20100630 Firefox/4.0b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1

While playing with other detachment issues, I noticed that things weren't working as expected when the target folder has a comma. I sent myself a test message with 3 trivial attachments in order to test what tb's behavior would be.

I used 3 target folders:

"Folder With Spaces"
"Only,Comma"
"Commas, Plus Spaces"

When using "Detach..." to save the files to these three folders, both target folders containing commas caused tb to truncate the saved pathname at the comma.

Here is the (nearly; I removed some headers) full message source after all 3 detachment operations:

Message-ID: <[e-mail]>
Date: Tue, 20 Jul 2010 10:22:38 -0400
From: Christopher Schultz <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1
MIME-Version: 1.0
To: Christopher Schultz <[e-mail]>
Subject: Attachment test
X-Enigmail-Version: 1.1.1
Content-Type: multipart/mixed;
 boundary="------------000205020508000107060104"

This is a multi-part message in MIME format.
--------------000205020508000107060104
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

This is a test message with attachments.


--------------000205020508000107060104
Content-Type: application/octet-stream;
 name="data with spaces.bin"
Content-Disposition: attachment; filename="data with spaces.bin"
X-Mozilla-External-Attachment-URL: file:///F:/Users/Chris/Desktop/Folder%20With%20Spaces/data%20with%20spaces.bin
X-Mozilla-Altered: AttachmentDetached; date="Tue Jul 20 10:24:49 2010"

You deleted an attachment from this message. The original MIME headers for the attachment were:
Content-Type: application/octet-stream;
 name="data with spaces.bin"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="data with spaces.bin"


--------------000205020508000107060104
Content-Type: application/octet-stream;
 name="data,with,commas.bin"
Content-Disposition: attachment; filename="data,with,commas.bin"
X-Mozilla-External-Attachment-URL: file:///F:/Users/Chris/Desktop/Only
X-Mozilla-Altered: AttachmentDetached; date="Tue Jul 20 10:25:09 2010"

You deleted an attachment from this message. The original MIME headers for the attachment were:
Content-Type: application/octet-stream;
 name="data,with,commas.bin"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="data,with,commas.bin"


--------------000205020508000107060104
Content-Type: application/octet-stream;
 name="data, with commas, and spaces.bin"
Content-Disposition: attachment; filename="data, with commas, and spaces.bin"
X-Mozilla-External-Attachment-URL: file:///F:/Users/Chris/Desktop/Commas
X-Mozilla-Altered: AttachmentDetached; date="Tue Jul 20 10:25:18 2010"

You deleted an attachment from this message. The original MIME headers for the attachment were:
Content-Type: application/octet-stream;
 name="data, with commas, and spaces.bin"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="data, with commas, and spaces.bin"


--------------000205020508000107060104--


Reproducible: Always

Steps to Reproduce:
1. Find a message with an attachment
2 [review]. "Detach" the attachment to a folder containing a comma
3. Right-click on the (still apparently active) attachment and choose "Save As..."
Actual Results:  
Message display window is replaced with error message:

File not found
The file /F:\Users\Chris\Desktop\Only cannot be found. Please check the location and try again.


Expected Results:  
Honestly, I'm not sure what the designed behavior is, here, but I would expect that if tb is going to remember the local path where the file was detached, it would store the pathname properly.

Also, should the user expect to be able to "Open" and "Save As..." for an attachment that has been detached (aka deleted)?

Another problem is, once the file has been detached, if the user moves the file from the original destination path and then tries to "Open" or "Save As...", the same error message is displayed (although due to the file actually not being there, not because the path is broken as per this bug report).

It might be nicer to display an error message that suggests that the file may have been moved after being detached, and now tb can no longer track it's location.

Comment 1

[Thomas D. (:thomas8)]

Confirming for Trunk: Mozilla/5.0 (Windows NT 5.1; rv:2.0b5pre) Gecko/20100820 Shredder/3.2a1pre

This misbehaves exactly as described in comment 0.

STR

1 have mail msg with attachment test.gif
2 "detach" test.gif and save it into file folder whose name contains a comma (with or without subsequent space), e.g. C:/Dokumente%20und%20Einstellungen/User/Desktop/folderfoo,bar/ OR .../folderfoo, bar/
3 right-click on test.gif in attachment pane, then
3a) Open...
3b) Save as...
3c) Double-click on test.gif (with no actions specified, i.e. no entry for Content-Type: image/gif in Tools > Options > Attachments, and "Always ask me where to save files" enabled)

Actual results

3a) Open: nothing, no error msg, no error in console

3b) Save as: no error in console, huge error msg covering all of msg preview pane (which I find weird), saying:

File not found
The file /C:/Dokumente und Einstellungen/Thomas/Desktop/folderfoo cannot be found. Please check the location and try again.
Check the file name for capitalization or other typing errors.
Check to see if the file was moved, renamed or deleted.
[Try again]

I really like the [Try again] button which is a good joke! (And, as the whole error msg, likely to cause confusion for the average user, although it's not easy to get this right...)

3c) Double-click: no reaction, no error msg, error console has

Error: uncaught exception: [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIChannel.open]"  nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)"  location: "JS frame :: chrome://messenger/content/msgHdrViewOverlay.js :: attachmentIsEmpty :: line 1581"  data: no]

and sometimes, before that (might be unrelated or due to fuzzy double-click on my notebook's touchpad):

Error: this._partMap[this._curAttachment] is undefined
Source File: file:///C:/Programme/Shredder/components/jsmimeemitter.js
Line: 393

The resulting headers look like this:

--------------030807090002050203010205
Content-Type: image/gif;
 name="test.gif"
Content-Disposition: attachment; filename="test.gif"
X-Mozilla-External-Attachment-URL: file:///C:/Dokumente%20und%20Einstellungen/User/Desktop/folderfoo
X-Mozilla-Altered: AttachmentDetached; date="Sun Aug 22 13:18:29 2010"


Expected results

3a should open test.gif (or prompt for whatever is needed to open it)
3b should let me do "save as" for test.gif to another location
3c should do whatever double-click on that content-type is supposed to do (according to default actions specified in Tools > Options > Attachments)

Technically, a comma in folder name should not truncate the link to the detached file, we should create a correct header, like this:

X-Mozilla-External-Attachment-URL: file:///C:/Dokumente%20und%20Einstellungen/User/Desktop/folderfoo,bar/test.gif

Iow, in the scenario of this bug, the error shouldn't occur.
If the user moves the detached file to another location (so the error occurs for a reason), we need to improve the error handling, which is not part of this bug but needs followup bugs if we don't have them yet.

Comment 2

[Thomas D. (:thomas8)]

(In reply to comment #1)
> If the user moves the detached file to another location (so the error occurs
> for a reason), we need to improve the error handling, which is not part of this
> bug but needs followup bugs if we don't have them yet.

Where improving the error handling, which may or may not be part of the fix for this bug, should include unifying the behaviour on error: It shouldn't matter if I click "Open", "Save as", or Double-Click, if the file isn't there, the behaviour on error should certainly be the same.

Comment 3

[Thomas D. (:thomas8)]

Christoph, thanks for your excellent bug report which made it easy to reproduce and confirm this bug.

Comment 4

[Christopher Schultz]

No problem. I'm a programmer and hate it when people say "it doesn't work" with no details ;) Let me know if there's anything I can do to help. I tried to look at XUL/js one day and nearly went cross-eyed. :(

Comment 5

[Nicolas Thierry-Mieg]

Isn't this the same bug as https://bugzilla.mozilla.org/show_bug.cgi?id=350825 ?

Comment 6

[Thomas D. (:thomas8)]

(In reply to Nicolas Thierry-Mieg from comment #5)
> Isn't this the same bug as
> https://bugzilla.mozilla.org/show_bug.cgi?id=350825 ?

Yes, thank you Nicolas!