Closed Bug 292385 Opened 19 years ago Closed 7 years ago

Need indication of detached attachment (overlay icon, 'Detached:' note etc.)

Categories

(MailNews Core :: Attachments, defect)

Product:
MailNews Core
Component:
Attachments
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1345167

People

(Reporter: mkmelin, Unassigned)

References

(Blocks 1 open bug)

Details

Detach an attachment. There is no visual (or other) indication in the "new"
message that the attachment has been detached. An icon and text "Detached:
filename" like for deleted files would be nice. 

Since the right-click menu does not indicate that the attachment is gone, you
can try to delete the detached attachment which does absolute nothing (the
deleted icon does not even appear.)

/version 1.0+ (20050429) linux
weird, because we do have both those things - a special icon for deleted
attachments (with a red x, iirc), and the name has "Deleted:" prepended to it.
I think you misunderstood me... We have an nice icon (and text) for *deleted*
attachments, but *detached* attachments display as if they were still part of
the message. Or are you saying I should see a detach icon? Because I'm really
not seeing any.

Maybe it should not be possible to do take the "delete" action of already
detached attachments, but currently that does not work.
ah, sorry, detached - I misread that as deleted. Well, for detached attachments,
I thought it would be nicer to keep the original icon for the attachment, since
for most intents and purposes, the attachment should function just like an
internal attachment. You're right that delete won't work for detached
attachments - unfortunately, it's not easy to know that the attachment is
actually detached, at the point where we enable/disable the delete attachment
command.
(In reply to comment #3)
> ah, sorry, detached - I misread that as deleted. Well, for detached attachments,
> I thought it would be nicer to keep the original icon for the attachment, since
> for most intents and purposes, the attachment should function just like an
> internal attachment. 

True for POP, but for IMAP users (like myself) accessing mail from many
locations it's mostly not true at all. 

> You're right that delete won't work for detached
> attachments - unfortunately, it's not easy to know that the attachment is
> actually detached, at the point where we enable/disable the delete attachment
> command.

<Uneducated guess>Hmm, but right-click-delete for deleted attachments is
disabled, shouldn't this be very similar?</Uneducated guess>


the way we disable delete for deleted attachments is that we look at the content
type, which is different for a deleted attachment. For a detached attachment,
the content type is not changed, since the content type is still valid; it's
just that the storage is external. So the same approach for disabling the menu
doesn't work.

For the imap case, we do need to fix the code that tries to launch external
attachments to give an appropriate error message if the external file is not there.
(In reply to comment #5)
> the way we disable delete for deleted attachments is that we look at the content
> type, which is different for a deleted attachment. For a detached attachment,
> the content type is not changed, since the content type is still valid; it's
> just that the storage is external. So the same approach for disabling the menu
> doesn't work.

If you don't want to change the Content-Type for detached attachments, maybe you
could just add a Content-Type parameter, like

Content-Type: application/x-zip-compressed;
	name="test.zip";
        mozstatus="detached"

... or something like that?

(In reply to comment #5)
> the way we disable delete for deleted attachments is that we look at the content
> type, which is different for a deleted attachment. For a detached attachment,
> the content type is not changed, since the content type is still valid; it's
> just that the storage is external. So the same approach for disabling the menu
> doesn't work.
> 
> For the imap case, we do need to fix the code that tries to launch external
> attachments to give an appropriate error message if the external file is not
there.

Taking up this discussion, it seems to me that the approach of considering
detachment as a change of storage from internal to external is too simplistic. 

As long as attachments are in the mail, coherence of data is ensured. The moment
an attachment is detached this coherence cannot be ensured anymore, since the
attachment can be moved from its initial destination without TB having any
knowledge of its change of location.

At the present, TB (version 1.0+ (20050811)) does not manage to open a detached
attachment even when the link is correct (when the link is copied from the
message into FF - default browser - the attachment shows up, which means the
link is OK.) So the external link mechanism is more deceptive than useful.

It would have been much better to clearly indicate in the attchement panel that
an attachment was detached giving its destination folder - all as pure text,
without trying to be too smart about the whole issue through a too fragile link. 

This will avoid considering TB faulty when it does not open a supposedly present
attachment which was detached and later moved.
(In reply to comment #7)
> (In reply to comment #5)
> > the way we disable delete for deleted attachments is that we look at the content
> > type, which is different for a deleted attachment. For a detached attachment,
> > the content type is not changed, since the content type is still valid; it's
> > just that the storage is external. So the same approach for disabling the menu
> > doesn't work.
> > 

> > For the imap case, we do need to fix the code that tries to launch external
> > attachments to give an appropriate error message if the external file is not
> there.
> 
> Taking up this discussion, it seems to me that the approach of considering
> detachment as a change of storage from internal to external is too simplistic. 
> 
> As long as attachments are in the mail, coherence of data is ensured. The moment
> an attachment is detached this coherence cannot be ensured anymore, since the
> attachment can be moved from its initial destination without TB having any
> knowledge of its change of location.
> 
> At the present, TB (version 1.0+ (20050811)) does not manage to open a detached
> attachment even when the link is correct (when the link is copied from the
> message into FF - default browser - the attachment shows up, which means the
> link is OK.) So the external link mechanism is more deceptive than useful.
> 
> It would have been much better to clearly indicate in the attchement panel that
> an attachment was detached giving its destination folder - all as pure text,
> without trying to be too smart about the whole issue through a too fragile link. 
> 
> This will avoid considering TB faulty when it does not open a supposedly present
> attachment which was detached and later moved.

An additional argument: since there is no indication that an attachment is
detached, there is no reason to not detach the attachment again, in which case a
very enigmatic error message appears, which makes absolutely no sense.

The mechanism relies too much on user awareness of what was done, and does not
take into account that more than one person can use TB with the same mail base.
I definitely aagree that there should be some visual notification that a attachment has been detached.  Even if the link to the attachment is just renamed to include **DETACHED**.  That way if someone tries to open it and it doesn't open, there would be a logical reason that the attachment has been moved (Maybe a message saying file was originally detached to "such and such", but is not longer available in that location.
related to bug 305485
this is still an issue
Thunderbird 1.5 (20051201) - this is still an issue. Creates a very confusing situation for users as there is no error message, there is no visual cue, and the context menu on the detached attachment still tries to behave as if the file is still attached. This is a great feature, but I consider its current state as egregiously flawed.
TB version 1.5 (20051222) now displays an error message when a detached file is not found in its destination folder (file renamed, for example). This is a bit better than earlier, but the lack of indication that a file was detached is confusing if the person trying to view the attachment does not know that it was detached.

The issue was fixed nicely for deleted attachments, with a crossed icon. Why not use an icon with a red arrow to indicate that the attachment was sent elsewhere? This should not be more difficult than with deleted attachments.
I managed it to crash TBird because of the missing indication.
So I filed bug 323531.
How about disabling the "Detach All..." feature in the context menu if there is no attachment eligible for detachment, analogous to how it is done for the "Save As...", "Open", "Delete" and "Detach..." menu items.

On a sidenote, while we're at it, not only "Detach All" should be disabled, but also "Save All..." and "Delete All..." when all attachments of a given message are already either deleted or detached. ATM, TB just does nothing and dumps "** failed to handle all attachments **" to the console.

There is already some logic in msgHdrViewOverlay.js:onShowAttachmentContextMenu() (see http://lxr.mozilla.org/mozilla/source/mail/base/content/msgHdrViewOverlay.js#1035), but it does not seem to work correctly.
(In reply to comment #15)
> How about disabling the "Detach All..." feature in the context menu if there is
> no attachment eligible for detachment, analogous to how it is done for the
> "Save As...", "Open", "Delete" and "Detach..." menu items.
> 
> On a sidenote, while we're at it, not only "Detach All" should be disabled, but
> also "Save All..." and "Delete All..." when all attachments of a given message
> are already either deleted or detached. ATM, TB just does nothing and dumps "**
> failed to handle all attachments **" to the console.

I filed bug #333904 for these issues.
QA Contact: front-end
As David told me on IRC we surely don't have an overlay icon which could be displayed for detached attachments. Arvid, are you still responsible for theming? If yes, do you have time to create such an overlay icon? Thanks.
Blocks: 416284
This really needs to be moved from Thunderbird to MailNews Core and from PC Linux to all platforms. I see this on SeaMonkey as well (ref bug 448678, comment 1) on OS/2.
Assignee: bienvenu → nobody
Component: Mail Window Front End → Attachments
OS: Linux → All
Product: Thunderbird → MailNews Core
QA Contact: front-end → attachments
Hardware: PC → All
I find this on Windows with Thunderbird:
 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/2008091421 Lightning/0.8 Thunderbird/2.0.0.17

If I do a delete/detach (single|all), nothing happens to the message on imap or pop.  if I detach the files end up where I direct them to, but the message still contains the attachments.
(In reply to comment #21)
> I find this on Windows with Thunderbird:
>  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/2008091421
> Lightning/0.8 Thunderbird/2.0.0.17
> 
> If I do a delete/detach (single|all), nothing happens to the message on imap or
> pop.  if I detach the files end up where I direct them to, but the message
> still contains the attachments.

Please verify the raw message (in Inbox): the message *looks like* it contains the attachments, but in fact the attachments are replaced by references to their new locations:

X-Mozilla-External-Attachment-URL: file:///C:/Documents%20and%20Settings/Owner/Desktop/picture.JPG
X-Mozilla-Altered: AttachmentDetached; date="Mon Sep 15 23:23:33 2008"

The original MIME headers for this attachment are:
Content-Type: image/jpeg;
 name="picture.JPG"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="picture.JPG"

The quest for an indication "Detached" instead of leaving the icon unchanged should avoid this mistake.
Joel, it will be another bug. This one is about an indicator which shows the attachment state. I think you are affected by bug 351224.
David, can you reply to comment 6 ?
Also why Content-Type / Content-Disposition can't just be changed ~like it is with the Deleted: case but here modify only name ?

mimemult.cpp
> nsCAutoString header("Content-Type: text/x-moz-deleted; name=\"Deleted: ");
> MimeWriteAString(obj, NS_LITERAL_CSTRING("Content-Disposition: inline; filename=\"Deleted:"));
This shouldn't be too hard to do, though I'm not at my dev box right now. Tentatively assigning it to myself for later.
Status: NEW → ASSIGNED
QA Contact: attachments → squibblyflabbetydoo
Assignee: nobody → squibblyflabbetydoo
QA Contact: squibblyflabbetydoo → attachments
Thanks Jim for taking up this old - but still relevant - issue.
Ok, so it's easy to figure out that an attachment has been detached while building the attachment list, but I have no idea how to overlay the icon to show that it's detached. Any ideas? (The easy solution is not to overlay at all and just show a "detached" icon.)
I have found a similar problem in :
Bug 327302 - Forward of a message with detached attachment should attach the
saved file. (dated 2006-02-15)
The user had no visual clue that the attachment has been detached : when (s)he
forwards it Tb send something (in fact the name of the detached file) that is
not the attachment. This is very misleading for the sender and the addressee !
 If the status of attachment (still attached, detached, deleted) was clearly visible (colour coding, icon, acronym, etc.) the bug 327302 may be alleviated by manually reattaching it.
In its comment 8, I have noted what is in the mailbox according the status.

Of course, the second part of bug 327302 (reattaching the file) is not part of the present bug but can you process it after you have solved the other attachment bugs ?

In answer to Comment 28, is it difficult to change the background or the font of the detached attachment name ?
(In reply to comment #30)
> I have found a similar problem in :
> Bug 327302 - Forward of a message with detached attachment should attach the
> saved file. (dated 2006-02-15)
> The user had no visual clue that the attachment has been detached : when (s)he
> forwards it Tb send something (in fact the name of the detached file) that is
> not the attachment. This is very misleading for the sender and the addressee !
>  If the status of attachment (still attached, detached, deleted) was clearly
> visible (colour coding, icon, acronym, etc.) the bug 327302 may be alleviated
> by manually reattaching it.
> In its comment 8, I have noted what is in the mailbox according the status.
> 
> Of course, the second part of bug 327302 (reattaching the file) is not part of
> the present bug but can you process it after you have solved the other
> attachment bugs ?
> 
> In answer to Comment 28, is it difficult to change the background or the font
> of the detached attachment name ?

Auto attachment of a detached file is not a good idea, since there is no guarantee that the file is still at the location where it was detached. Once a file is detached it should no longer have any live link to the message. 

If you forward a message you should be aware that the file was detached, and attach it yourself. Evidently, TB should remind you that a file was detached - this is the whole idea of this column.
(In reply to comment #31)
"Auto attachment of a detached file is not a good idea, since there is no
guarantee that the file is still at the location where it was detached. Once a
file is detached it should no longer have any live link to the message. "
1) The right place to discuss this is bug 327302, please read it and post in it.
2) I disagree. If you read comment 8 of bug 327302 you will see that TB has recorded in the message in the mailbox the time/date of detach and the complete path of the destination file. So it has the information needed to check if the attachment file is still here in the destination repertory and has the good time stamp. As TB does not show this informations to the user, TB is in a better situation to reattach (or give an error message if the file is not found or has been modified) than the user ! I think that in more than 95 % of the case the attached file has not been moved, deleted or modified so it is a good idea that TB itself process the file or in the other cases give me the informations recorded as a starting point to find the file to be attached manually.
(In reply to comment #32)
> (In reply to comment #31)
> "Auto attachment of a detached file is not a good idea, since there is no
> guarantee that the file is still at the location where it was detached. Once a
> file is detached it should no longer have any live link to the message. "
> 1) The right place to discuss this is bug 327302, please read it and post in
> it.
> 2) I disagree. If you read comment 8 of bug 327302 you will see that TB has
> recorded in the message in the mailbox the time/date of detach and the complete
> path of the destination file. So it has the information needed to check if the
> attachment file is still here in the destination repertory and has the good
> time stamp. As TB does not show this informations to the user, TB is in a
> better situation to reattach (or give an error message if the file is not found
> or has been modified) than the user ! I think that in more than 95 % of the
> case the attached file has not been moved, deleted or modified so it is a good
> idea that TB itself process the file or in the other cases give me the
> informations recorded as a starting point to find the file to be attached
> manually.

The two bugs in question are open since 2005/2006, which means that nobody cares enough to do anything about them. I will be satisfied if TB just displayed the "Detached" status, which for me is more important than auto-reattach a detached message.
(In reply to comment #32)
"...if TB just displayed the "Detached" status, which for me is more important than auto-reattach a detached message."
You are right, this bug is more important than bug 327302 and the solution of the first one will alleviate the 2nd.
The first one is assigned to Jim Porter who works also on other attachment bugs and needs some time (but not too long, I hope) to solve all of them. I am less optimistic for bug 327302 !
Ludovic, do you know somebody who can help with Jim's comment 28?

(In reply to Jim Porter (:squib) from comment #28)
> Ok, so it's easy to figure out that an attachment has been detached while
> building the attachment list, but I have no idea how to overlay the icon to
> show that it's detached. Any ideas?
Summary: need indication of detached attachment → Need indication of detached attachment (overlay icon, 'Detached:' note etc.)
(In reply to Thomas D. from comment #35)
> Ludovic, do you know somebody who can help with Jim's comment 28?
> 
> (In reply to Jim Porter (:squib) from comment #28)
> > Ok, so it's easy to figure out that an attachment has been detached while
> > building the attachment list, but I have no idea how to overlay the icon to
> > show that it's detached. Any ideas?

Maybe Neil knows.
Since I don't know what you're referring to, I'm guessing you meant the other Neil.
(In reply to Jim Porter from comment #28)
> I have no idea how to overlay the icon to show that it's detached. Any ideas?
I think you might be currently using your custom descriptionitem-iconic binding for attachments, in which case you can tweak it so that your current image is nested in a stack with a second image. You then use

.descriptionitem-iconic[attachmentIsExternal="true"] {
  list-style-image: url("chrome://messenger/skin/icons/detachedOverlay.png");
}

in your theme. The first image in the stack will inherit this image. The second image in the stack should use xbl to inherit the attachment icon as before.
using isExternal from the mime object doesn't differentiate between remote feed enclosure links and local disk file detached attachments.  the user will get the wrong idea if they are treated the same, the former triggers a remote download, there could be security/privacy implications.

imo X-Mozilla-Altered gives the most precise indication of a detached attachment.  it just needs to be emitted: Bug 633837.
(In reply to alta88 from comment #40)
> using isExternal from the mime object doesn't differentiate between remote
> feed enclosure links and local disk file detached attachments.  the user
> will get the wrong idea if they are treated the same, the former triggers a
> remote download, there could be security/privacy implications.

Then we should just check if the external attachment URL begins with "file://" or not.
I'm not currently working on this, so unassigning myself.
Assignee: squibblyflabbetydoo → nobody
Status: ASSIGNED → NEW
Shouldn't this be pretty easy to fix since the attachment seems to have headers like:

X-Mozilla-External-Attachment-URL: file://FILENAME-PATH
X-Mozilla-Altered: AttachmentDetached; date="Thu Apr 04 08:47:38 2013"

For someone knowing the code this very useful feature could hopefully be implemented quickly. It doesn't have to be a nice "overlay icon", if that's the problem.
In about a month this topic will be 10 years old (notwithstanding a status NEW). Quite outstanding for an issue in these fast changing times.
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.
I was about to report the same.
This is really essential for proper bookkeeping! Otherwise you could as well delete the whole message right away in many cases.
I have lived (happily) since I raised this topic. Consequently, as far as I am concerned, this issue can be closed.
The patch in Bug 1345167 linkifies external attachments, on hover displays the file or http url of the attachment, and shows a strikethrough/tooltip for external items no longer found at the original location.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
See Also: → 1663437
You need to log in before you can comment on or make changes to this bug.