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.

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

dupes?

there's a bunch of these

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

(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

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

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.

(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?

richard is gone