User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 When you have a mail with attachments and you right-click on an empty area of the attachment pane in the message preview you get the context menu for the previous selected attachment (it doesn't auto de-select it) even if it was of another message. I think it should auto deselect the old attach and give the save all context menu as you're clicking on an empty area and not on a particular file... Reproducible: Always Steps to Reproduce: 1. Select a file attached to a message in the bottom attachment pane in the message body 2. Go to another message with attachment(s) 3. Right-click on an empty area of the bottom attachment pane Actual Results: You get the Open - Save As etc context menu. If you try to open or save as it saves the still selected attachment of the first message Expected Results: I think it should open the Save All etc context menu deselecting the old selected attach. It happens in safe-mode, too. Easy Workaround: left-click on an empty area before righ clicking

Is this also true in -safe-mode (http://kb.mozillazine.org/Safe_mode)?

yes it is, as written 4 lines above :D

(In reply to comment #2) > yes it is, as written 4 lines above :D Sorry I missed it.

np, thanks for the reply instead ;)

Forwarding CC's of duplicate bug 516294 which has more information on related attachment focus bugs in bug 516294, comment 4.

I'm in agreement with bug 516294, comment 4, in fact I was about to comment there. Attachments is heavily used and our story for 3.0 isn't very good right now [1]. so seems like we should want this bug and maybe others (related?) fixed for 3.1, perhaps even port to 3.0. [1] Other click/select bugs Bug 533921 - Right click on a blank attachment pane area shows the context menu for the previous selected attachment Bug 537826 - Attaching replaced files, with right click "Send To", sends old file if the file names are the same Bug 503125 - IMAP server - deleting attachment removes attachment from previously viewed message Bug 514785 - File -> Attachments dialog missing on email with attachments Bug 518891 - detach/delete attachment does neither: results in duplicate email w/attachment Bug 536964 - Can't save mail attachments when select Save All... menu item OT A ton of old attachment bugs in General and should be moved. And more generally, attachment bugs need a good overhaul/retriage https://bugzilla.mozilla.org/buglist.cgi?keywords=hang%20crash;type0-1-0=nowordssubstr;keywords_type=nowords;field0-1-0=short_desc;short_desc=attachment;field0-0-0=component;bug_severity=critical;bug_severity=major;bug_severity=normal;bug_severity=minor;resolution=---;query_format=advanced;value0-1-0=tags%20search;longdesc=click;short_desc_type=allwordssubstr;type0-0-0=nowordssubstr;value0-0-0=mime%20compos%20search;product=MailNews%20Core;product=Thunderbird;longdesc_type=allwordssubstr

From the duped from bug: Along the lines of Phil's comment 2: What if we could just make attachment pane UI behave like any other list of files in Finder, Gnome File Browser, and Windows Explorer? For a start, respect focus for keyboard inputs. Always. How about a view option for the attachment box "view all parts as a list" This would be regardless of content-disposition , viewing options, etc. There are just too many situations where intended content is masked/ignored. So with this option for example, a background image in an html composition would be viewed inline, as well as being available in the attachment pane as part of the "list" I think something like that was available way back in NN4.x As I recall, it was View | Page info which listed all the parts of a multi-part message.

(In reply to comment #8) > > ...just make attachment pane UI behave like any other list of files in > > Finder, Gnome File Browser, and Windows Explorer > How about a view option for the attachment box "view all parts as a list" Yes, that sounds like an interesting idea. The following bug proposes something similar, but only for "normal" attachments (not all parts): Bug 360647 - Need configurable view for list of attachments (implement alternative view modes, should have view for attachment details) > This would be regardless of content-disposition , viewing options, etc... > As I recall, it was View | Page info which listed all the parts of a > multi-part message. Considering that the HTML part of a mail isn't much different from a normal HTML page, this makes a lot of sense and might even be easy to implement if we can borrow from the implementation of the Firefox Page Information dialogue.

(In reply to comment #7) > [1] Other click/select bugs Setting dependency of the bugs to Bug 503125 for ease of problem analysis and tracking.

If I'm understanding this correctly, it could result in some actual data loss if you saved the wrong attachment and then deleted the message. So I'm marking this blocking. Blake or Phil, are either of you up for digging into this a little? I have a vague recollection of Phil expressing his undying love for this code.

David, I believe dataloss is far easier to achieve than comment 11 has it: Select an attachment in msg1, then view msg2, right-click on empty space of attachment pane in msg2, delete -> will delete attachment of msg1 rather than attachment of msg2. This can easily happen if you miss clickable area of attachment of msg2 by some px with the mouse. Possible solution for this bug, taken from bug 472286, comment 5: > The only sensible fix for this is to clear the selected attachment when an > email is clicked on. Anything else will be prone to problems when someone does > something that you are not expecting. This sounds like a safe way of avoiding any confusion about selected attachments from previous messages: just set whatever variable the attachment selection is saved in to nothing /as soon as/ user views another message. That's much safer than waiting for the user to select something new and only then trigger the unselection of the old. In fact, perhaps we could unselect even earlier, when exiting display of the previous msg, if that's possible. Furthermore, may I point out Bryan's reading recommendation of bug 473901, comment 15: > For anyone working on this you might want to read over this: > https://developer.mozilla.org/en/XUL_Tutorial/Focus_and_Selection > and this might still have relevant info: > https://wiki.mozilla.org/XUL:Focus_Behaviour Quote (from XUL_Tutorial/Focus_and_Selection): > The focused element refers to the element which currently receives input > events. ... *Only one element per window has the focus* at a time. > The user can *change the focus* by *clicking an element* with the mouse or by > pressing the TAB key. When the TAB key is pressed, the next element is given > the focus. Simple. Following these rules without any exceptions will solve the whole plethora of attachment-focus-related bugs that currently present a nightmare to keyboard users. Imagine having a clean, simple, and predictable attachment UI. Applied to this bug: - right-clicking on attachment blank space is a click on an element - a click on an element triggers a change of focus (according to the rules) - in this case: attachment pane should get focus (whole pane should have dotted border) - show correct context menu for attachment pane (save all, detach all etc.) - to avoid confusion about selection scope, unselect any selected attachments when user right-clicks on blank space, as per bug 516294 comment 2: > because that's what the Finder, the Gnome File Browser, and Windows > Explorer, where most people get their expectations for the behavior of icons > representing files, all do.

I don't really have time now, so I'll let Phil take the first crack at it. ;) (I might have more time before beta 1, so if it's still not being worked on by then, I'll see what I can do.) Sorry about that, Blake.

Giving to bwinton, but moving out to RC1, as this isn't a new feature, nor does the fix appear to require strings.

I can't imagine that this actually needs a ui-r, but just in case. Lemme know if you want a try-server build, Bryan. Thanks, Blake.

Comment on attachment 443440 [details] [diff] [review] A patch to clear the selected attachments. nit - you can lose the commented out line: + mc.click(new elib.Elem(attachmentList.children[0])); + //mc.click(new elib.Elem(attachmentList.children[1])); I don't think you need ui-review on this. It's a bug fix...

This should be the patch that gets committed once the trees re-open. Carrying forward r=bienvenu.

Committed as: http://hg.mozilla.org/comm-central/rev/3bdff8b699b7 and http://hg.mozilla.org/releases/comm-1.9.2/rev/0c4c66e9c2df