Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.4) Gecko/20100608 Lightning/1.0b2 Thunderbird/3.1 STR: - left-click on one out of multiple attachments in attachment pane - try to use keyboard to act on any attachment from inside the pane, *without using mouse*: - select one or more or all attachments - try any other action on attachments (open, save, detach, delete) Actual result: - attachment is selected, but not focussed (no dotted border) - keyboard users have NO WAY AT ALL of acting on any attachment from inside the pane (for details of broken keyboard interaction, see further information below). This bug clearly violates the following UI rules, as laid out in the XUL_Tutorial/Focus_and_Selection: 1 clicking on elements moves focus to that element 2 focus receives keyboard input 3 there can only be one focus at a time https://developer.mozilla.org/en/XUL_Tutorial/Focus_and_Selection https://wiki.mozilla.org/XUL:Focus_Behaviour Expected result: - single-left-clicking on attachment should select and focus it (focus follows mouse click as per above rules) - attachments in attachment pane should be fully keyboard-accessible, i.e. when focus (and selection) is on attachment, attachment should receive all relevant keyboard input (irrelevant keyboard input can still be used for acting on the message, like ctrl+R) - attachments are presented as file objects, so they should behave just like any other file object in the OS (at least on windows) Further information: We definitely have a big usability problem here, and it's a REGRESSION compared to TB2 and even TB3.0.x. In TB3.1RC2, attachment pane is no longer keyboard accessible, *AT ALL*. Instead, TB breaks basic usability rules in that focus does not follow mouse clicks. The sad overall perspective is this: - clicking on an attachment file object does not place the keyboard focus in attachment pane (this is a gross violation of basic user interaction patterns, and the source of most of the following misbehaviour) - cannot use <tab> (or F6) to place focus into attachments pane - cannot use <cursor> keys to navigate in attachments pane (e.g. select the 5th out of 10 attachments for viewing, saving, detaching, or deleting) - cannot use <shift>+<cursor> to select multiple adjacent, but not all attachments - cannot use <ctrl>+<cursor> with <space> to select/deselect multiple non-adjacent attachments - cannot use Ctrl+A to select all attachments (cf. bug 281046) - cannot use [shift]+DEL to delete selected attachments (cf. bug 315144) - cannot get ANY contextual menu for attachments via keyboard (e.g. context menu key on Windows) What's worse, there's reason to assume that such incredibly bizzare, counter-intuitive, deviant and discriminating UI behaviour might actually be intended, for the absurd reason of securing all-time keyboard access to the message list; the absurdity being that it comes at the cost of breaking keyboard access for attachments in attachment pane, completely. That's replacing one evil (small and necessary) by another one (big and inacceptable).

Thomas can you look for when this regressed ?

(In reply to comment #1) -> We need someone to find the regression range... any volunteers? Unfortunately I'm not able to, as I don't have the build environment set up and I wouldn't know yet how to find the regression range. I'd believe that 3.0.x still had a way of keyboard navigation, selection, and operation in attachment panel (which would render the potential regression range pretty small) but I'm not 100% sure.

You don't need to build. http://www.rumblingedge.com/2009/02/24/howto-find-regression-windows-through-manual-binary-search/

Narrowing down the regression range (someone else, please continue!): - this bug is NOT in Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 - first time I consciously saw this was in 3.1rc2 20100608, but it might have been there before - it IS in trunk, and iirc it was in trunk quite a while before it landed in branch (I remember commenting somewhere that we should pray to be spared by this ui nightmare in the branch) - could this one have caused the regression? Bug 533921 - Right click on a blank attachment pane area shows the context menu for the previous selected attachment

> Bug 533921 - Right click on a blank attachment pane area shows the context menu > for the previous selected attachment > -> could that one have caused the regression? ping? (In reply to comment #4) > Narrowing down the regression range (someone else, please continue!): any volunteers for the regression range? This bug blocks a lot of other bugs as it makes attachment pane keyboard-inaccessible (see Blocks field). Which is very bad. - It should be given a high priority flag (like P2). - It should have a notice on the whiteboard (ux-prio) - wanted 3.1 flag must be removed (as it's out of the door) - wanted-thunderbird+ should be added

Bryan, to avoid more epic stories, could we have some supportive/acknowledging feedback on comment 0, and flag-twisting as requested by comment 5?

I thought this changed before 3.0.3, i.e. in the betas in alpha. but comment 4 might be correct. If it is correct, then it would have been affected by one of these bugs fixed in v3.0.4 https://bugzilla.mozilla.org/buglist.cgi?field0-0-0=cf_status_thunderbird30;type0-0-1=equals;field0-0-1=cf_status_191;query_format=advanced;value0-0-1=.9-fixed;type0-0-0=equals;value0-0-0=.4-fixed

This bug should be marked blocking-thunderbird 3.2 and should be fixed asap (details in my previous comments here). As getsatisfaction dissatisfaction report http://gsfn.us/t/1c9xy points out, we have an additional color problem that's probably caused by this bug: When selecting multiple, potentially non-adjacent attachments, we now indicate the selection only by a very light-grey background color, which is almost indistinguishable from the white background of the attachment pane. Which makes it very hard to see which attachments are selected and which aren't. This is another regression over TB2, where we used reverse highlighting colors with a clear contrast to indicate selection, like white text on blue background.

I have a work-in-progress fix for this in bug 282068, which will probably get in, assuming there aren't some non-obvious problems I'm missing.

Fixed by bug 630759.