Victor Tsaran Reporter
	Description • 16 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Build Identifier: 

After attaching one or more files to the outgoing message, it is impossible for a keyboard user to interact with any of them because the list of attachments does not appear in the tab order.

Reproducible: Always

Steps to Reproduce:
1. Start composing a message.
2. Attach one or more files to your message through file->attach menu.
3. Use TAB or SHIFT+TAB key to locate the list of attachments
Actual Results:  
You will not be able to reach the list of attachment via keyboard.

Expected Results:  
TAB or SHIFT+TAB key should locate the list of attachments.

	Magnus Melin [:mkmelin]
	Comment 1 • 16 years ago

xref bug 373996

	Phil Ringnalda (:philor)
	Comment 2 • 16 years ago

Actually, bug 215846 might be a better xref, that being where SeaMonkey got fixed so that two of the three strangely barely different focus-switchers worked for it. So, in SM, either F6 or ctrl+tab will go addresswidget - subject - attachment - body, while tab will go addresswidget - subject - body (at which point you're stuck, because tab won't get you out), but in Tb, we have all three different keys that all go addresswidget - subject - body.

	Phil Ringnalda (:philor)
	Comment 3 • 16 years ago

Err, what I meant to say was "in Tb we have both ctrl+tab and tab going addresswidget - subject - body and only F6 going addresswidget - subject - attachment - body"

	Victor Tsaran Reporter
	Comment 4 • 16 years ago

Thanks a lot. After your explanation this makes a bit more sense. I would never guess though.
I can now reach the list of attachments by pressing CTRL+SHIFT+TAB but not with CTRL+TAB. With the latest trunk of TB CTRL+TAB never seems to land o nthe "attachments" list.

	Thomas D. (:thomas8)
	Comment 5 • 15 years ago

Note that we cannot rely on ctrl+tab unless we are in a standalone compose window, as eventually we will have tabbed composition where ctrl+tab switches between tabs.

A) IMO we should add a single stop to include attachment panel in the <tab> sequence, for the following reasons:

1) the only reason-of-being for <tab> sequences is easy and intuitive keyboard accessibility (general access key for keyboard users and disabled people): I don't quite see on what grounds we are excluding an important part of composition from such no-fuss accessibility. <tab> and <ctrl+tab> are the "master keys" of access, as they are always available without having to remember all sorts of keyboard shortcuts. Both keyboard users and disabled people will appreciate intuitive access (F6 is NOT intuitive).

2) adding the a /single/ <tab> stop for attachment pane provides easy access to /all/ relevant attachment-related commands: Open, Remove, Rename(!), Select All, Add File(!), Add Web Page, and Add V-Card (currently missing). That's access to 7 commands at the price of 1 stop. That's a pretty good cost-benefit 
ratio.

3) with current layout, the extra <tab> stop will only be effective when attachment panel is actually visible: users /without/ attachments aren't affected at all, and users /with/ attachments will certainly appreciate the comfort.
 
4) the main <tab> sequence in case of 3) is still very short:
For Ctrl+Tab/F6, we have 4 stops now (Sender, Address widget, Subject, Body), so that's 5 stops if we implement this (Sender, Address widget, Subject, Attachment pane, Body), and only when there actually are attachments.

5) We're just adding a /single/ stop in attachment pane even if there are multiple attachments (these are focused by cursor keys). That's really nothing compared to the number of stops the user can potentially add himself by having more than one recipient (2 extra <tab> stops for each recipient). Which might be wrong design, but right now it's a fact.

B) With regards to <ctrl><tab>, it will only work for the focus ring when we are in a non-tabbed layout (stand-alone compose window). In that case, I can't see any reason why we shouldn't add a single stop to include attachment pane in the fast-track sequence (like SeaMonkey), as it's an important section of the compose window, and we're not using <ctrl+tab> for anything else.

	Thomas D. (:thomas8)
	Comment 6 • 15 years ago

Bryan, this is a trivial change to ensure attachment pane keyboard accessibility while composing. Could we have ui-review from you for the following two changes (detailed reasons in comment #5):

A) Add a single <tab> stop for attachment pane in composition window (effective only when it's visible = has attachments)

B) Add a single <ctrl+tab> stop for attachment pane in composition window (like SeaMonkey; only for standalone/non-tabbed composition)

	Bryan Clark (DevTools PM) [:clarkbw]
	Comment 7 • 15 years ago

Thomas, this looks good to me.

I'm adding Marco just to get a quick opinion on how the tab order could work best.  Marco, comment 5 has the details for how the tab order works.  Essentially we'd be adding the attachment panel to the tab order in between the subject and the content pane when the attachment panel is visible.  Thanks!

	Marco Zehe (:MarcoZ)
	Comment 8 • 15 years ago

(In reply to comment #7)
> Essentially we'd be adding the attachment panel to the tab order in between the
> subject and the content pane when the attachment panel is visible.  Thanks!

This is the best place to put it indeed! Thanks!

	Thomas D. (:thomas8)
	Comment 9 • 15 years ago

Comment on attachment 410502 [details]
Screenshot: add tab stop at composition's attachment pane (only if it's shown)

I assume that's ui-review+ based on Bryan's comment 7 and Marco's comment 8.

	Thomas D. (:thomas8)
	Comment 10 • 15 years ago

Comment on attachment 410502 [details]
Screenshot: add tab stop at composition's attachment pane (only if it's shown)

(In reply to comment #9)
> (From update of attachment 410502 [details])
> I assume that's ui-review+ based on Bryan's comment 7 and Marco's comment 8.

Bryan, would you set the flag for ui-review+?

	Thomas D. (:thomas8)
	Comment 11 • 15 years ago

(In reply to comment #6)
> Created an attachment (id=410502) [details]
> Screenshot: add tab stop at composition's attachment pane (only if it's shown)
> 
> Bryan, this is a trivial change to ensure attachment pane keyboard
> accessibility while composing. Could we have ui-review from you for the
> following two changes (detailed reasons in comment #5):
> 
> A) Add a single <tab> stop for attachment pane in composition window (effective
> only when it's visible = has attachments)
> 
> B) Add a single <ctrl+tab> stop for attachment pane in composition window (like
> SeaMonkey; only for standalone/non-tabbed composition)

And, obviously:
C) Add a single <F6> stop for attachment pane in composition window

	Thomas D. (:thomas8)
	Comment 12 • 15 years ago

In much the same way, bug 373996 should be addressed, only that we can't use <ctrl+tab> there because we're in tabbed mode where <ctrl+tab> switches tabs.

	Bryan Clark (DevTools PM) [:clarkbw]
	Comment 13 • 15 years ago

Comment on attachment 410502 [details]
Screenshot: add tab stop at composition's attachment pane (only if it's shown)

yes, ui-r+

sorry about that Thomas

	Thomas D. (:thomas8)
	Comment 14 • 15 years ago

Never mind, and thanks!

Bryan, while you're at it, could you also comment and grant UI-review+ for twin bug 373996, comment 12, which proposes the same accessibility pattern as here, but for the /message reader/ preview and standalone window?

Keyboard/disabled users will certainly appreciate if we provide a uniform UI approach to keyboard-handling of attachments both when composing and when reading messages.

	Bryan Clark (DevTools PM) [:clarkbw]
	Comment 15 • 15 years ago

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

	Thomas D. (:thomas8)
	Comment 16 • 14 years ago

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.7) Gecko/20100713 Lightning/1.0b2 Thunderbird/3.1.1

The behaviour has improved a bit for TB 3.1.1, but still unexpected and incomplete (compared to the ui-reviewed+ behaviour of attachment 410502 [details])

1) attachment pane inaccessible in forward tab sequence (tab from subject takes you to msg body instead of attachment pane and then you're stuck as tab will be written into the msg text)

2) attachment pane inaccessable in forward ctrl+tab sequence, which is inconsistent with correct behaviour in F6 sequence (see 4)

3) unexpectedly, either shift+tab or ctrl+shift+tab from msg body will NOT go back to subject, but to the attachment pane (iow, forward [ctrl+]tab behaves different from [ctrl+]shift+tab, which is confusing and undiscoverable behaviour)

4) F6 has the correct tab stop sequence, including attachment pane if present

	Thomas D. (:thomas8)
	Comment 17 • 14 years ago

(In reply to comment #16)
> 4) F6 has the correct tab stop sequence, including attachment pane if present

That's
4) F6 has the correct sequence of stops, including attachment pane if present

	Jim Porter (:squib) Assignee
	Comment 18 • 13 years ago

Here's a fix for this, which should address all the problems in comment 16. I removed some code that forced "tab" in the subject to focus the message body. I don't think it was needed (it works fine without it in Linux), but it might be worth trying it out on other platforms just to be safe.

I also removed the code that selects the first attachment when focusing the attachment pane via F6, since that behavior is inconsistent with pretty much every other listbox/tree in Thunderbird.

	Blake Winton (:bwinton) (:☕️)
	Comment 19 • 13 years ago

Comment on attachment 554271 [details] [diff] [review]
Fix this

Review of attachment 554271 [details] [diff] [review]:
-----------------------------------------------------------------

The code looks pretty good.  r=me, after you add some tests.  ;)

Thanks,
Blake.

	Jim Porter (:squib) Assignee
	Comment 20 • 13 years ago

Here are some tests for F6 and Ctrl+Tab. Pulling forward r+.

	Jim Porter (:squib) Assignee
	Comment 21 • 13 years ago

Checked in http://hg.mozilla.org/comm-central/rev/e111751bcbba