448588 - Thunderbird is less helpful and consistent than it might be when saving multiple attachments and overwriting files

Status: RESOLVED DUPLICATE of bug 448580

(Thunderbird :: Message Reader UI, defect)

Description

[Richard Mlynarik]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
Build Identifier: Attachment "Save All.." and "Detach All..." file(s)-already-exist overwrite UI improvement

(I have no idea whether this problem is Macintosh UI specific or more generally broken.)

If I have a message with multiple attachments and attempt to save them
into a directory in which one of more filenames already exist with names
the same as those of the attachment the series of dialogs offered to the
user to resolve the problem is inadequate, inconsistent and confusing.

Case 1: File with name same as that of first attachment already exists.

1.1. Display a message with multiple attachments.
1.2. Click-right on attachments and select "Save All..." from the context menu. 
1.3. Choose a directory in which a file with the same name as that which will be Thunderbird-internally chosen for the first attachment already exists.
1.5. For each attachment for which a file exists, Thunderbird pops up a dialog
offering
> Confirm
> /tmp/already-exists-1.text already exists.  Do you want to replace it?
with choices "Cancel" and "OK".

PROBLEM 1:
It is unclear what the "Cancel" button will do.
It turns out that it means "Do not overwrite this one file but instead pop up a replacement dialog asking the user for a new filename", but it could equally plausibly have meant "Cancel entire Save All/Detach All action"

SUGGESTION 1:
Replace simple Cancel/OK dialog with three unambiguous choices:
> Warning
> /tmp/already-exists.text already exists.  Do you want to replace it?
* Cancel Save
* Choose another file [selected by default]
* Replace existing file

SUGGESTION 2:

Provide a checkbox in this dialog "Apply to all attachments", meaning to
make the same choose-another/replace-existing choice for all remaining attachment, but I'd much rather instead see implemented suggestion 3, which
supersedes it.

SUGGESTION 3:

Before saving ANY attachments into any files, first check whether there would
be any already-exists filename conflicts for any attachment, and if so offer
a set of choices to the user in a dialog:
> Warning
> File(s) attachment-file-1.text, attachment-file-2.jpg and attachment-file-3.text already exist.
> Do you wish to
* Cancel
* Overwrite existing files
* Save only non-existing attachments
* Choose new files for existing attachments
* Choose files for every attachment

The last two choices would pop up a choose file dialog for each relevant attachment.


Case 2: File with name same as that of second attachment already exists
while file for first attachment does not exist.

1.1. Display a message with multiple attachments.
1.2. Click-right on attachments and select "Save All..." from the context menu. 
1.3. Choose a directory in which a file with the same name as that which will be Thunderbird-internally chosen for the first attachment does not exist, but the second does.
1.5. Thunderbird saves the first attachment and pops up its generally unhelpful and apparently vestigial and inherited-from-Mozilla and otherwise-inaccesible "Downloads" window.)
1.5. For each attachment for which a file exists, Thunderbird pops up a dialog
offering
> Confirm
> /tmp/already-exists-2.text already exists.  Do you want to replace it?
with choices "Cancel" and "OK".

SUGGESTION 3:

Thunderbird is inconsistent about popping-up the Downloads window.
If the first save fails because a file already exists (Case 1 above) it does
not appear, but in the second case it does.

Either it should always appear or never.
And given that I can find no menu item that causes this this Downloads window to be displayed (in Firefox it's under Tools / Downloads) other than as a transient side effect of overwriting attachments, I'd be inclined to remove it altogether.  What practical purpose does it serve?



Case 3: File with name same as that of first attachment already exists.

3.1. Display a message with multiple attachments.
3.2. Click-right on attachments and select "Save All..." from the context menu. 
3.3. Choose a directory in which a file with the same name as that which will be Thunderbird-internally chosen for the first attachment already exists.
3.4. For each attachment for which a file exists, Thunderbird pops up a dialog
offering
> Confirm
> /tmp/already-exists.text already exists.  Do you want to replace it?
with choices "Cancel" and "OK".
3.5. Select "Cancel" (which, as noted above in Suggestion 1, does not really mean "Cancel [operation]", but instead means "Choose a different file"
3.6. A new dialog pops up, offering "Save Attachment", and defaulting to the already extant file.  The only choices are "Cancel" and "Save"

SUGGESTION 4: It is ambiguous what "Cancel" means in this context.
Does it mean "Cancel attempt to save this one attachment and proceed to
subsequent attachments" (which is what it means in the Confirm dialog we
saw just seconds ago in step 3.4) or does it mean "Cancel entire Save All/Detach All" operation?

Well, it turns out, inconsistently, that in this dialog it means "Cancel entire operation for all attachments".

The "Cancel" option in this dialog should be unambiguously named.

SUGGESTION 5: An additional option action button "Skip" should be offered,
meaning to not save this attachment but to go on the subsequent attachments.
This would be separate from and in addition to an unambigously-named Cancel
all saves button.

3.7. Choose "Save" and attempt to overwrite the existing file anyway.

3.8. A new dialog pops up
> An item named already-exists.text already exists in this location.
> Do you want to replace it with the one you are saving?
* Cancel
* Replace

SUGGESTION 6: This is a different dialog from the one presented in step 3.4!
How many different file-already-exists dialogs with binary replace-or-cancel
choices does one piece of software need?

SUGGESTION 7: It is ambiguous what "Cancel" means in this context.
Does it mean "Cancel attempt to save this one attachment and proceed to
subsequent attachments" or does it mean "Cancel attempt to overwrite this
file and go back and ask the user for another file name", or does it mean
"Cancel entire Save All/Detach All" operation?

Well, it turns out, inconsistently, that in THIS dialog it means
"Cancel attempt to overwrite this file and go back and ask the user
for another file name", which of course is different from the last
two meanings of "Cancel" the last two times we saw that button in
a dialog!

The "Cancel" option in this dialog should be unambiguously named.

I could go on...

See also Bug 448580: Attachment "Save All..." and "Detach All..." UI should optionally allow per-attachment filename choice

Reproducible: Always

Steps to Reproduce:
See above
Actual Results:  
My head explodes

Expected Results:  
Simple, straightforward, consistency.

"Cancel" should mean one thing.

It should be obvious what that one thing is, and it shouldn't have three different meanings in three successive and similar-appearing dialogs.

Information about potential filename conflicts should be gathered up in
one pass and presented to the user, enabling the user to optionally
make a global choice about all attachments, rather than always having
to answer the same questions for each file.

See for example how typical OS file-manager GUIs work when copying/renaming
multiple files by drag-and-drop and one or more target files already exist.
It's ought to be pretty easy to make something like TB to work at least that well.

Comment 1

[Tyler Downer [He/Him]]

Any more suggestions? Just joking.
But, I agree, the name is a bit confusing. 

Comment 2

[Wayne Mery (:wsmwk)]

dupes?

Comment 3

[Wayne Mery (:wsmwk)]

there's a bunch of these

Comment 4

[[:Aureliano Buendía]]

(In reply to comment #2)
> dupes?

I think that we can close it as dupe of bug #187091, that covers the major issue.

Comment 5

[Wayne Mery (:wsmwk)]

(In reply to comment #4)
> I think that we can close it as dupe of bug #187091, that covers the major
> issue.

that may be one possibility.  Some of Richard's suggestions may align with bugs in the query below.  But ...

Bryan, who was working on an extension for attachments?  Point being, are Richard's comments helpful?

https://bugzilla.mozilla.org/buglist.cgi?type1-0-0=anywordssubstr;short_desc=attach;emaillongdesc1=1;field0-0-0=short_desc;bug_severity=blocker;bug_severity=critical;bug_severity=major;bug_severity=normal;resolution=---;classification=Client%20Software;classification=Components;emailtype1=substring;chfieldto=Now;query_format=advanced;chfieldfrom=2009-01-01;short_desc_type=allwordssubstr;email1=clarkbw;type0-0-0=nowords;value0-0-0=count%20counts;field1-0-0=short_desc;product=MailNews%20Core;product=Thunderbird

Comment 6

[Wayne Mery (:wsmwk)]

squib, (I'm guessing you know most of the bugs in Bug 579473, so without investing a lot of time) is there anything in comment 0 that worth spinning off and is not mentioned in bugs linked to Bug 57947? 

If there isn't, we can close this as a duplicate or invalid

Comment 7

[Jim Porter (:squib)]

We could probably spin this off to a bug that's just about renaming the buttons in the "do you want to overwrite this file" dialog. But 448580 should cover the renaming situation, more or less.

Comment 8

[Wayne Mery (:wsmwk)]

(In reply to Jim Porter (:squib) from comment #7)
> We could probably spin this off to a bug that's just about renaming the
> buttons in the "do you want to overwrite this file" dialog. 

Richard Mlynarik, can you file a bug for the above?

Comment 9

[Wayne Mery (:wsmwk)]

richard is gone