63889 - Tab order in the compose window.

Status: VERIFIED DUPLICATE of bug 95844

(MailNews Core :: Composition, defect, P1)

Description

[scottputterman]

We have a bunch of bugs for specific tab order but I don't know if we have one 
for general.  We should make tab order work correctly. That should include 
getting to the From field as well as the header fields (to, cc, etc).  I've cc'd 
Jennifer. Do we want to include the attachment pane?  If so, what should be the 
tab order?

Comment 1

[scottputterman]

marking nsbeta1+ and moving to mozilla0.8 reassigning to varada.

Comment 2

[scottputterman]

moving to mozilla0.9

Comment 3

[Jesse Ruderman]

Is this a metabug? (31248,31250,49217,...)

Comment 4

[scottputterman]

*** Bug 31248 has been marked as a duplicate of this bug. ***

Comment 5

[varada]

Accepting bugs.

Comment 6

[varada]

Marking Fixed.
The tab order now is 
From(foo) <->
Header(to/cc/bcc..)<->Address([e-mail])[<->Header()<->Address()]<->Subject
<-> MessageBody.

Comment 7

[esther]

Varada,  I don't see how to get to the Header (To..CC...BCC) did this part 
break.  Also, this bug mentions the Attachment area.  Once a user (using 
keyboard only) adds an attachment, I don't see how they can remove it (using the 
keyboard).  It has a mnemonic but it doesn't work.  reopening for review.

Other bugs marked duplicate of this one are about Attachment needing a mnemonic 
(which it has 62703, but it doesn't work due to 959)

Comment 8

[scottputterman]

moving to 0.9.2

Comment 9

[varada]

Patch in hand

Comment 10

[scottputterman]

Please attach the patch.

Comment 11

[scottputterman]

moving to 0.9.3.  Please hold onto the fix in case we can get this in later.

Comment 12

[varada]

Attachment: Patch V 1.0

Comment 13

[Jean-Francois Ducarroz]

I wonder if this patch we cause the edit field to lose focus when you select an
item in the recipient type fropdown menu! If it's the case, do we really want that?

Comment 14

[varada]

We do lose focus on the edit field next to it and it is the same behaviour for
tabbing in 4.x. We retain focus even when we use the mouse to do the selection
and 4.x gives back the focus to the edit field after the selection. We can
probably have a event listener to give back focus to the edit field after each
selection.

Comment 15

[Jean-Francois Ducarroz]

I like your proposition of setting the focus into the next edit field after
selecting a recipient type.

However, if the user use only keyboard navigation into the dropdown list, we
should not change the focus. Imagine you are not using your mouse but only the
keyboard and want to enter a newgroup:
1) Tab until the focus is into the recipient type dropdown list
2) press the down arrow until you have selected the right item
3) tab to go to the edit field.

In no case, the focus should change while using the up/down arrow keys!

Comment 16

[scottputterman]

moving to 0.9.4

Comment 17

[Scott MacGregor]

I'm a bit fuzzy on the contents of this bug. Does the patch make us match the
spec or are there still some concerns? If the patch is ready to go and we are
happy with it, let's get it checked in. Otherwise, we need to move .9.5 and
finish working out the issues there.

Comment 18

[Scott MacGregor]

Not  a .9.4 stopper so we'll have to continue this discussion in .9.5.

Comment 19

[scottputterman]

moving to 0.9.6

Comment 20

[scottputterman]

moving to 0.9.7

Comment 21

[scottputterman]

IT looks like http://bugzilla.mozilla.org/show_bug.cgi?id=95844 is a dup of this
since it would be included in this fix.  Anyone disagree?

Comment 22

[scottputterman]

reassigning to ssu.

Comment 23

[Sean Su]

yep.  looks like a dupe of bug 95844.  marking it so.

*** This bug has been marked as a duplicate of 95844 ***

Comment 24

[Olga]

Verified dup.