1113310 - No indication that "Detach" from attachment context menu actually deletes the attachment (and UX problems when detached file is moved/deleted/renamed -> separate bug required)

Status: RESOLVED DUPLICATE of bug 292385

(Thunderbird :: Untriaged, defect)

Description

[Jeff Bloomfield]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 20141126041045

Steps to reproduce:

Running MacOS 10.6.8 on X86_64 x86_64

1. Open an email message with an attachment
2 [review]. Right click on the attachment label for the attachment context menu
3. Select "Detach" or "Delete"



Actual results:

Appropriate warning message comes up.
Selected the appropriate "go ahead and do it" button.


Expected results:

Attachment is never deleted from mail message.

[Another thunderbird bug that's been around for years]

Comment 1

[Jeff Bloomfield]

Specific Comment: This bug has been around for years.

General Comment : Another year of having to search for add-ons or put up with workarounds to retain 
                  functionally of previous version and I will finally give up on Thunderbird.

When I have time I will post on blog:  

Why not set a group priority to fix most of Thunderbirds long-outstanding bugs before adding ANY new 
features. Most users want a mail client that works, rather than a patchwork of add-ons to hold on to basic functionality. Personally, I want a functioning Thunderbird more than I want any new features.

Comment 2

[Jeff Bloomfield]

Specific Comment: This bug has been around for years.

General Comment : Another year of having to search for add-ons or put up with workarounds to retain 
                  functionally of previous version and I will finally give up on Thunderbird.

When I have time I will post on blog:  

Why not set a group priority to fix most of Thunderbirds long-outstanding bugs before adding ANY new 
features. Most users want a mail client that works, rather than a patchwork of add-ons to hold on to basic functionality. Personally, I want a functioning Thunderbird more than I want any new features.

Comment 3

[Jeff Bloomfield]

[Don't see a way to edit my original bug text]

Expected Results:

Attachment should be deleted from the mail message

Comment 4

[WADA:World Anti-bad-Duping Agency]

(In reply to Jeff Bloomfield from comment #0)> 
> Steps to reproduce:
> 1. Open an email message with an attachment

What kind of folder?  (i) IMAP folder, (ii) local folder(POP3 or Local Folders"
What folder type?       (iii) Real Folder, (iv) Virtual Folder(Search Folder)
    Note: If View/Folder/Unified, each Unified folder is (iv), and each folder with account name is (iii) 
If IMAP, what is you IMAP delete model choice? (Server setings, When I delete a message:)
   (v) Move to trash, (vi) Just matk it as deleted, (vii) Remove it immediately
Where did you open mail?
  (a)- message pane of 2pane window
  (b)  message window, with "open in existing message window"
  (c)  message window, with "open in new message window" 
  (d)  tab, with "open in tab"
If (b)/(c)/(d), how did you open message window or tab?
  (e) Menu/Context menu of Threaad Pane
  (f) "Open" at SearchDialog

> Actual results:
> Attachment is never deleted from mail message.

At where is phenomenon of "attachment is not deleted" observed?
  (g) message pane or message window or tab where a message is shown
  (h) Thread pane, or SerchDilog
After your Detach or Delete Attachment operatiion,  was original deleted from Thread pane of the folder? Or still remained?
How bout new version by Detach/Delete Attachment?
Was "Order Received" column value8messageKey) or Size of tha mail changed after your Detach/Delete?
Was duplicte mail generated by your Detach/Delete?

Same problem as Bug 1089452?
If different, what part is same but what part is different?

Comment 5

[Jeff Bloomfield]

Attachment: My T-bird settings for their IMPAP server

Comment 6

[Jeff Bloomfield]

Answering Wada's questions:

What kind of folder? IMAP folder

What folder type?    Real folder

    Note: If View/Folder/Unified, each Unified folder is (iv), and each folder with account name is (iii)
 
If IMAP, what is you IMAP delete model choice? When I delete a folder, move it to the Trash

Where did you open mail? (both (a) and (d) below:
  (a)- message pane of 2 pane window 
  (d)  tab, with "open in tab"

If (b)/(c)/(d), how did you open message window or tab?
Neither - With Inbox visible in the top main window, I double-click the message, which opens it in a new tab _OR_
I single-click the message and see its text in the bottom main window.

NEXT-From either the message tab or the bottom main window displaying the message, I right-click on the attachment
field and choose "Delete". 

The message box pops up "CONFIRM: The following attachments will be permanently deleted from the message" <filename>.pdf. This action cannot be undone. Do you wish to continue"

I click "OK" Then the message line in the top main window blinks for a moment.
RESULT: The message and its attachment are unmodified (verified by double-clicking on the message attachment field)

At where is phenomenon of "attachment is not deleted" observed?
  (g) message pane or message window or tab where a message is shown?  ALL of these locations--nothing was changed
  (h) Thread pane, or SerchDilog -- I don't use this feature.

After your Detach or Delete Attachment operatiion,  was original deleted from Thread pane of the folder? Or still remained? Still remained (see above)

How bout new version by Detach/Delete Attachment? DON'T KNOW WHAT YOU MEAN BY THIS QUESTION


Was "Order Received" column value8messageKey) or Size of tha mail changed after your Detach/Delete?  NO CHANGE



Was duplicte mail generated by your Detach/Delete?

Comment 7

[Jeff Bloomfield]

Attachment: fetch>UID>.INBOX>108518.INBOX%3E108518

Comment 8

[Jeff Bloomfield]

From saving "Message Source", Attachment:  fetch>UID>.INBOX>108518.INBOX%3E108518 

--===================_0022_0022====__
Content-Type: application/pdf; charset="us-ascii"
Content-Disposition: attachment; filename="S2068095_2457798.pdf"
X-Mozilla-External-Attachment-URL: file:///Users/jeffb/Eclectic/2014/Clients/pending/Bachina-2206Tenth/S2068095_2457798.pdf
X-Mozilla-Altered: AttachmentDetached; date="Thu Dec 18 21:54:57 2014"

Sorry. For some reason the operation completed tonight. I'll have to wait until I get it to fail again.

---------------

You deleted an attachment from this message. The original MIME headers for the attachment were:
Content-Type: application/pdf; charset="us-ascii"
Content-Disposition: attachment; filename=S2068095_2457798.pdf
Content-transfer-encoding: base64


--===================_0022_0022====__--

Comment 9

[Jeff Bloomfield]

Attachment: Insurance Renewal.eml - Message Body/Deleted Attachment which still opens (very weird)

See attachment "Insurance Renewal.eml"

The attachment was "Detached" from the message source, yet I can still open the attachment by clicking on it! Is T'bird following the path to where it was
saved on my disk??? (and using Preview.app to open it???).

I think the clue to this weird behavior might be found in comparing the new message sources I've attached to this bug.  Hope this helps.


The message source says (fragment; attachment contains whole message source):

Content-Type: application/pdf;
 name="Jeff Bloomfield Renewal.pdf";
Content-Disposition: attachment; filename="Jeff Bloomfield Renewal.pdf"
X-Mozilla-External-Attachment-URL: file:///Users/jeffb/Eclectic/2015/insurance/Jeff%20Bloomfield%20Renewal.pdf
X-Mozilla-Altered: AttachmentDetached; date="Thu Dec 18 12:32:20 2014"

You deleted an attachment from this message. The original MIME headers for the attachment were:
Content-Transfer-Encoding: base64
Content-Type: application/pdf;
 name="Jeff Bloomfield Renewal.pdf";
Content-Disposition: attachment;
 filename="Jeff Bloomfield Renewal.pdf";


--=_36dce033956ffdafa5fa982ecf8192fa--

Comment 10

[Jeff Bloomfield]

Question:  What is the difference between in the attachment context menu between:

a) Detach - which pulls up a "Save As" dialog; and

b) Save As - which also pulls up a "Save As" dialog ???

Comment 11

[Magnus Melin [:mkmelin]]

Save as just saves a copy. Detach saves the file, then deletes the file from the actual message, but leaves a link to where in the filesystem you saved the copy.

Comment 12

[Jeff Bloomfield]

Thank you Melin. From your description of "Detach" and "Save", I think this bug (and maybe the related bug) should be closed and a new, lesser priority bug should opened in the case of "Detach" 

Here's why: 

Scenario #1:
============

1. The user selects "Detach" (by right-clicking on the message attachment button (from any kind of message window), sees the message box warning that the attachment will be deleted from the message, and then selects a location in the filesystem to save the attachment.

2. After Step #1, the message attachment button still shows: "1 attachment: <filename> xxx bytes. Double-clicking or context-menu "Open" opens the file by passing the original saved <pathname> to whatever app can open the file type. The user can also by right-click context-menu to "Save-As", which is simply making a copy of the disk file to a new location in the filesystem. A message box should pop up with something like:

"This email message no longer contains this attachment, since you previously saved <filename> to <pathname> on your disk. Thunderbird will now open <pathname> using the app <appname>."

OR if the user selected "Save As" from the context menu, the message box should say something like:

"This email message no longer contains this attachment, but the file does exist at <pathname>. T'bird will now copy (or overwrite) <pathname> to <new-pathname>"

Scenario #2:
============
1. Outside of T'bird the user has deleted, renamed, or moved (yes I know: an ordinary user believes rename/move appear are  different operations).

2. The user returns to T'bird and views the same email message. The message attachment button now says:

"1 attachment: <filename> 0 bytes" or "1 attachment size unknown"

3. The user attempts to open the attachment (double-click--the context menu choices are greyed-out).
Double-clicking simply produces a silent no-op.  IMHO, double-clicking should produce a message box with something like:

"This email message no longer contains the attachment contents of <filename> because you previously
saved <filename> to your disk at <pathname> and <pathname no longer exists. Outside of T'bird you have
either:

o Renamed the file; or
o Changed the files location (path); or
o Both the above

Also IMHO, the context-menu should not be greyed out. Instead, its choices should produce the above-proposed message box.

Scenario #3
===========
The user has deleted the attachment.  The message attachment button says:

"1 attachment Deleted: <filename> 0 bytes"

This current behavior actually makes sense!

SUMMARY:
========
I'll listen to people's opinions before I decide whether to open a new bug.

Comment 13

[Jeff Bloomfield]

Oops.

In the above comment in Scenario #2, Step 3, forget to add the case of user externally deleting file. E.G.:

"This email message no longer contains the attachment contents of <filename> because you previously
saved <filename> to your disk at <pathname> and <pathname no longer exists. Outside of T'bird you have
either:

o Renamed the file; or
o Changed the files location (path); or
o Both the above; or
o Deleted the file

Comment 14

[Thomas D. (:thomas8)]

Yeah, detaching has poor ux, and is very uncooperative.

Bug 292385 - no indication of detached attachment
[Bug 286283] Detaching attachments: Need to fix titles of save/select folder dialogues (correct/improve/clarify captions)
[Bug 901350] detaching attachments doesn't update the status line (mail size)
etc.

Also, we should allow user to change link to file saved from attachment manually, if moved in file system. If we don't have a bug for that yet, it should be filed.

I agree with Jeff we'd need an error msg if detached/linked attachment was moved in file system and thus can no longer be found. If there's no bug yet, it should be filed.

I don't have time for all the details of comment 12...

Jeff, can you provide one or a couple of one-line summaries of what's left of this bug?

Comment 15

[WADA:World Anti-bad-Duping Agency]

(In reply to Jeff Bloomfield from comment #9)
> The attachment was "Detached" from the message source,
> yet I can still open the attachment by clicking on it!

Same question as comment #4 again.

At where is phenomenon of "attachment is not deleted" observed?
  (g) message pane or message window or tab where a message is shown
  (h) Thread pane, or SerchDilog
After your Detach or Delete Attachment operatiion,  was original deleted from Thread pane of the folder? Or still remained?
How bout new version by Detach/Delete Attachment?
Was "Order Received" column value8messageKey) or Size of tha mail changed after your Detach/Delete?
Was duplicte mail generated by your Detach/Delete?

Same problem as Bug 1089452? If different, what part is same but what part is different?

Comment 16

[Thomas D. (:thomas8)]

(In reply to WADA from comment #15)
> (In reply to Jeff Bloomfield from comment #9)
> > The attachment was "Detached" from the message source,
> > yet I can still open the attachment by clicking on it!
> 
> Same question as comment #4 again.
[Snip]
> Same problem as Bug 1089452? If different, what part is same but what part
> is different?

WADA, there's no need for detailed technical analysis any more because reporter has already stated in comment 12 that this bug can be closed. Reporter was a victim of Bug 292385 - there's no explicit UI indication whatsoever about the fact of a detached attachment (perhaps a tooltip with file path to copy saved on user's system, but that's not sufficient). Also, "Save as..." dialogue title for "Detaching" is misleading, insufficient contrast with the real "Save as..." dialogue which creates a copy while preserving attachment in msg. So reporter "admitted" that the main part of this bug is invalid (he was mislead by our poor UI to believe that the attachment is not deleted), and what remains are "lesser priority" RFE's/Bugs to improve the UX when the link to detached attachment file is used, esp. when the local copy has been deleted/renamed/moved.

I've pointed existing bugs and potential needs for new bugs/RFE's in my comment 14.
So next step would be check if all of the suggestions in comment 14 are covered by bugs, and file new bugs if not. After that, this bug can be closed without further technical discussion.

Jeff, the unfortunate truth is that "detaching" does no longer appear to be a frequent usecase that deserves a priority share of our precious/scarce programmer time resources. But we might still find somebody to code up the error message in case the attachment file was moved/deleted/renamed in file system. That's if we manage to offer a clear bug with a clear focus on a small, single item.

Can you help us with filing bugs per comment 14?
Can you help us with fixing those bugs?

Comment 17

[Thomas D. (:thomas8)]

WADA, there are clear indications in comment 0 that Jeff's analysis was not technically sound, but just based on (wrongly) perceived user experience: 

Points in STR vs. Actual Result vs. Expected result are in a mess. E.g. Expected result of comment 0 is nonsense, because it's really the Actual Result - very confusing. Bugs with poor description rarely work out, so it's futile to try and force users into detailed technical analysis. From my experience, it's sometimes better to NOT assume new and fancy technical bugs, but rather assume that user might have wrong understanding/expectations, inadequate description/wording, or is just facing the current UI/UX with the shortcomings/failures we already know.
This bug should have been closed invalid as filed; at least put tag "obsolete" on STR, and file better STR in a new comment.

To avoid spending more time here, I'll close this as a duplicate of the main issue which triggered this bug report, which is Bug 292385.

Comment 18

[Thomas D. (:thomas8)]

(In reply to Jeff Bloomfield from comment #2)
> Specific Comment: This bug has been around for years.

...and is certainly not the only one! The problem comes with numbers: Many bugs, few developers. All of us volunteers.

> General Comment : Another year of having to search for add-ons or put up
> with workarounds to retain 
>                   functionally of previous version and I will finally give
> up on Thunderbird.

I'm only aware of very few cases where we really removed functionality, e.g. the view switcher and the summary columns in folder list. Due to popular demand, we're adding the summary columns back.
Recent problems with recipient autocomplete are also in the process of being fixed.
Pls email me with any important issues beyond that.

> When I have time I will post on blog:  
> 
> Why not set a group priority to fix most of Thunderbirds long-outstanding
> bugs before adding ANY new 
> features. Most users want a mail client that works, rather than a patchwork
> of add-ons to hold on to basic functionality. Personally, I want a
> functioning Thunderbird more than I want any new features.

That sounds nice in theory (and I'd even agree with that general tendency), but doesn't work out in practice. Again, too many bugs (including many long-standing), too few developers. In fact, the new features we've added in the last couple of releases are very few, nothing that reinvents the wheel, so practically we're already following that policy.

The good news is we're actually fixing long-standing important bugs, but perhaps its not always those that affect you personally.