User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 Build Identifier: version 1.5 (20051201) "Save All..."/"Detach All..."/"Delete All..." attachment context menu items should be disabled if all attachments of that message are already detached/deleted. It should be analogous to how it is done for the "Open", "Save As...", "Detach..." and "Delete" menu items. Reproducible: Always Steps to Reproduce: 1. Open message 2. Delete/detach all attachments 3. Open attachment context menu Actual Results: The "Save All..."/"Detach All..."/"Delete All..." menu items of popup "attachmentListContext" are enabled. Expected Results: The "Save All..."/"Detach All..."/"Delete All..." menu items of popup "attachmentListContext" should be disabled. onShowAttachmentContextMenu() should disable "context-saveAllAttachments", "context-detachAllAttachments" and "context-deleteAllAttachments" in popup "attachmentListContext". See http://lxr.mozilla.org/mozilla/source/mail/base/content/msgHdrViewOverlay.js#1035.

See also bug 328293

(In reply to comment #1) > See also bug 328293 I guess these two bugs could all be solved in the same code, i.e. loop over all attachments (variable "currentAttachments"), to detect if there are any non-deleted/detached attachments. Add a counter inside the loop which counts "good" attachments, and then break if the counter equals two (i.e. more than one, which fixes bug 328293) Something along these lines: for (var i = 0, count = 0; count != 2 || i < currentAttachments.length; i++) if (currentAttachments[i].contentType != "text/x-moz-deleted") count++; if (count == 2) { foo.removeAttribute('disabled'); bar.removeAttribute('disabled'); }

(In reply to comment #2) Scratch that! It must be: for (var i = 0, count = 0; count != 2 && i < currentAttachments.length; i++) of course. What was I thinking...

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a2pre) Gecko/20070112 SeaMonkey/1.5a] (nightly) (W2Ksp4) Confirming with SeaMonkey. Furthermore, trying to actually delete leads to an alert dialog. In case some attachments are already deleted and some are not, it is needed to delete the remaining ones one by one (= workaround): the already deleted attachments should not be listed in the confirmation dialog...

In TB, when an attachment is detached TB conserves a link to the attachment's new location. Such a link is very flimsy, since the attachment can now be moved by the file manager and TB will not be informed, killing the link. The presence of a link should disable all actions on the attachment. However, since there is no indication of the detachment, the user may not understand why actions are disabled. To ensure coherence, two things should be done simultaneously: (1) display the fact that an attachment was detached and (2) disable further actions (including display) on a detached attachment.

Fixed this in bug 416284.