97918 - autocomplete tab-order behavior should be consistent (regardless of component)

Status: NEW

(MailNews Core :: Composition, defect)

Description

[Quinn Yost (mythdraug)]

While many issues have been raised in bug 86643 and bug 79006,
they both fail to get to the heart of the matter.  The behavior
of autocomplete should be IDENTICAL regardless of where it occurs.

Comment 1

[Quinn Yost (mythdraug)]

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

Comment 2

[Sheela Ravindran]

nbaca, 
Please reassign this to yulian if this is not your area.

Comment 3

[Keyser Sose]

Marking these all WORKSFORME sorry about lack of response but were very
overloaded here. Only reopen the bug if you can reproduce with the following steps:

1) Download the latest nightly (or 0.9.6 which should be out RSN)
2) Create a new profile
3) test the bug again

If it still occurs go ahead and reopen the bug. Again sorry about no response
were quite overloaded here and understaffed.

Comment 4

[Grey Hodge (jX)]

Seems to WFM here, but I'll let someone else double check to be safe.

Comment 5

[Jesse Ruderman]

In the browser, the URL bar autocomplete dropdown has an entry in the tab order
for every item in the dropdown.  This is extremely annoying.  In mail, pressing
tab fills in the first match and jumps to the subject field, which makes sense.

One reason for there to be a difference is that in the browser, the next
focusable item isn't the Go button but the current page.  I think the best
solution would be to change the URL bar to have only one entry in the tab order
(and leave mail as it is).

Comment 6

[Jean-Francois Ducarroz]

-->varada

Comment 7

[(not reading, please use [e-mail] instead)]

taking all of varada's bugs.

Comment 8

[R.K.Aa.]

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

Comment 9

[Steve McMillen]

While I agree regarding the need for consistency between the browser and email
address autocomplete, I disagree that the current behaviour in the email client
is the ideal behaviour for these reasons:
1. tab has become a ui standard for autocomplete.  Bash and DOS shells use tab
to autocomplete.  In DOS it cycles between choices. The mozilla and other
browsers use this behavior
2. Tab is a very convenient means of choosing from the list becuase you don't
need to move your fingers off the asdf-jkl; keys.  The email componsition window
requires you to press arrow keys which is very annoying since I need to loose my
place on the keyboard.
3. More people use the browser and are probably used to the current behaviour
that the browser implements.

I strongly urge that this bug be fixed by making the email composition window
behave like the browser in that typing tab should move to the next item in the
autcomplete list.  Typing shift-tab should move to the previous item.  The enter
key must be typed in order to select an address.  Typing enter moves focus to
the next empty line in the message header.  One more tab key moves focus to the
subject line as expected.

Comment 10

[Mike Cowperthwaite]

(In reply to comment #5)
> In the browser, the URL bar autocomplete dropdown has an entry in the tab
> order for every item in the dropdown.  This is extremely annoying.

I'd never noticed this, because I'd never think tab in the URL field with an AC 
list open, and I don't understand why anyone would!  If I want to select an item 
from the dropdown, I'll use the mouse or the arrow keys -- just like in a normal 
dropdown list.  (Note that in Moz products, <tab> from an open dropdown list 
seems to simply close the list without changing the selection, but without 
moving on to the next focus item.  That doesn't seem like the best behavior to 
me, either.)

IE does this one-tab-stop-per-item in the URL bar's AC list; Opera (v. 6 and 7) 
moves the focus out without even completing (which is lame, I think).  
See bug 249532 comment 2 for the behavior of Safari and Mail.app on a Mac -- 
there, again, tab fills in the item with the selection and moves to the next 
field.


> In mail, pressing tab fills in the first match and jumps to the subject field,
> which makes sense.

The other big difference between the address and URL widgets is: when the 
autocomplete box opens, it fills in the rest of the address field with the first 
choice (and that filled-in text is selected).  In this case, you don't need a 
Tab to indicate "choose the first completion option" because that has already 
been visibly chosen.

But Tab has a very well-defined meaning in the address fields, compared to 
Enter:  Enter means "select this address and let me enter a new address" whereas 
Tab means "select this address and move on to the Subject."  Using Tab to pick 
the selection from the list

Outlook Express doesn't *do* autocomplete on mail-compose addresses.

 
> One reason for there to be a difference is that in the browser, the next
> focusable item isn't the Go button but the current page.

Or, in FF, the Search field.


> I think the best solution would be to change the URL bar to have only one
> entry in the tab order (and leave mail as it is).

I don't really care what happens with the URL AC list's handling of Tab; but 
changing autocomplete in the mail compose window would break it.

Comment 11

[Ed Lee :Mardak]

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

Comment 12

[(not reading, please use [e-mail] instead)]

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.

Comment 13

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 14

[Wayne Mery (:wsmwk)]

Karsten, can you suggest a way forward for resolving this bug?   A change in resolution or component?  I'm not sure TB would entertain a change in behavior, but cc:ing bryan