Closed Bug 205666 Opened 21 years ago Closed 16 years ago

Compose Window's Attachment box focus indication is flawed

Categories

(Thunderbird :: Message Compose Window, defect)

defect
Not set
minor

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: mcow, Assigned: mscott)

References

(Depends on 1 open bug)

Details

(Whiteboard: closeme 2008-06-19)

If the focus in the Compose Window has been placed on the Attachment box, there 
is not necessarily a visual indicator of that fact.  Focus can be placed on the 
box by clicking it, or by pressing the hotkey for the label (alt-C in 1.4b, 
alt-A in earlier versions).

 - If the box is empty, there is never an indicator of focus.
 - When an attachment is added (via the file menu, the toolbar, or 
single-clicking on the attachment box itself), there is still no indication of 
focus.
 - Click on the attachment entry: the entry is now shown as selected, and if the 
focus is removed, the selection is still shown, faded.
 - Ctrl-click on the (single) selected entry: the entry is now shown with a 
dotted outline (a "nonselection"); if the focus is removed, the outline is 
erased, but is re-drawn if focus is restored to the box.

Once a file has been selected, the box will always show a selection or a 
nonselection; the nonselection cannot be removed (except by deleting all 
attachments), but it can be moved to other items or hidden by an actual 
selection.  So, once a file has actually been selected, the box has a focus 
indicator.

If the Attachments box contains files but no [non]selection, and the focus is 
shifted to the box (either using the hotkey, or single-clicking below the file 
list and then either cancelling or choosing an additional attachment), then 
typing the down-arrow key will select the first item.

Recommended: a shadowy outline (similar to that of the From dropdown) when the 
box has focus; plus, automatically adding a "nonselection" when the first 
attachment is, um, attached.

xref bug 73715.

This likely applies to all OS/platform.
Depends on: 230904
Product: MailNews → Core
I have learned the "nonselection" described above is properly called the 
"current".

The behavior has improved with recent TB trunk builds, due to bug 280153 having 
been fixed.  (I'll check Seamonkey as soon as I can get to it.)  This is good 
because TB previously (in 1.0.x if not earlier) wasn't showing a "current" 
indicator at all, just the selection, and so was even less functional.
Moz 1.7.x behaves as originally described.


Now (with TB, anyway): when an attachment is added: if you attach by dragging an 
item, the focus remains where it was previously; if you attach via the toolbar 
or menu item, the focus shifts to the attachment box.  In the latter case, there 
is initially no indication of focus ("current" is not displayed) -- however, 
shifting focus to another field and back, or shifting to a different window and 
back, now will show the "current" indicator at the attachment.  So there *is* a 
focus indication available now without having to click the item.  

The symptom where the indicator is not shown for the first attachment added via 
menu or toolbar should still be fixed; it could be fixed by causing the box 
display to be more complete when the attachment is shown, and/or by not shifting 
the focus when adding an attachment (as is the case with Moz 1.7).  I think 
making *both* changes would be good.


Note that with TB, the attachment panel is usually not displayed until an 
attachment has actually been added, and is hidden again if all the attachments 
are deleted.  So, the problem of not showing a focus indication for an empty box 
is almost not a problem.  There is one case where TB *will* show an empty 
attachment box: if you drag an item over the headers, then cancel the drag, the 
box pops into view and then doesn't disappear.  There is still no indication of 
focus for this case; I'm presuming Seamonkey still shows this problem, and I 
don't know if there's a solution, if the "current" indicator is not intended for 
use in an empty list.
(In reply to comment #1)
> (I'll check Seamonkey as soon as I can get to it.)

No, this fix is not in Seamonkey -- the patch for bug 280153 is "Toolkit" only: 
Firefox/Thunderbird.  Therefore, I'm moving this bug out of the suite; I've also 
retargeted bug 230904 to the Toolkit 'product'.
Assignee: sspitzer → mscott
Component: MailNews: Composition → Message Compose Window
OS: Windows 2000 → All
Product: Core → Thunderbird
QA Contact: esther
Hardware: PC → All
QA Contact: message-compose
Mike, does this still occur in the latest 2.0.0.14 / trunk nightlies?
Whiteboard: closeme 2008-06-19
TB 3a1pre-0419 (yes, I know, it's old)

(In reply to comment #1)
> if you attach by dragging an item, the focus remains where it was previously;
> if you attach via the toolbar or menu item, the focus shifts to the
> attachment box. 

No longer true; focus remains where it was in all three cases.


> Note that with TB, the attachment panel is usually not displayed until an 
> attachment has actually been added, and is hidden again if all the
> attachments are deleted.  

No longer disappears when all attachments deleted.  However, you can click on the empty attachment box, then escape from the file-select dialog; or, you can have the focus on the attachment box and <del> all the attachments away; or, you can <Alt+C>.  At this point, you can't see where the focus is -- not on any of the other fields, not visibly on the attachment box; no response to Enter.  F6 or Tab at this point puts the focus on the message body.

I guess this means that the only remaining issue is bug 230904.

F6 navigation does not put focus on the attachment box when it is empty.  If the attachment box is not empty, F6 will eventually put the focus there

(Tab navigation always skips the attachment box.)


> So, the problem of not showing a focus indication for an empty box 
> is almost not a problem.  There is one case where TB *will* show an empty 
> attachment box: if you drag an item over the headers, then cancel the drag,
> the box pops into view and then doesn't disappear.  There is still no
> indication of focus for this case

This is no longer a problem; the focus remains on the previous field.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.