Open Bug 263946 Opened 20 years ago Updated 2 years ago

menu kbd navigation in Message Filters (and other places) seems wrong

Categories

(Toolkit :: XUL Widgets, defect)

x86
Linux
defect

Tracking

()

People

(Reporter: brendan, Unassigned)

References

Details

(Keywords: access)

I can't get the popups to do the right thing by arrow-keying down (e.g. to
"begins with" instead of "contains" for a subject match) and hitting tab. 
Someone shoot me if it's correct to have to hit enter to select that item --
it's not that way on all other apps I use, on Linux or Windows (or Mac, for that
matter).

/be
I'm confused :)

All of our menu list items like this require you to hit enter before they go
into effect in mailnews. Ditto for firefox. Try scrolling through your history
from the urlbar, we don't actually select said url item until you hit enter. Or
the views menu in mailnews, the quick search drop down, 

I believe we are consistent with the rest of the menu lists at the application
level. I know HTML menulists work differently.

If there is some push to make a XUL menu list widget behave differently it
should come from the toolkit layer and not a special case instance of the menu
list in the filter dialog.
mscott: I'm not sure why Message Filters sticks out to me, maybe it's always
been that way in Mozilla mail/news and in Thunderbird.  But consider HTML menus
such as Target Milestone in this very bug: you can arrow-key around after
tabbing into the menu, and tab takes focus to the next input (link or form
element) in tab-key-nav order.

Why does Message Filters make my fingers and head hurt?  (Yeah, the URL bar's
history makes me flinch too -- half the time I tab to confirm and have to arrow
up one and hit Enter).  Are we doomed to having web form widget tab-key-nav
rules differ from XUL ones?  Or is there an example of a popup in XUL somewhere
that behaves the same as the HTML popups?

/be
Target Milestone: --- → mozilla1.8alpha4
Forgot the punch-line:

> But consider HTML menus
> such as Target Milestone in this very bug: you can arrow-key around after
> tabbing into the menu, and tab takes focus to the next input (link or form
> element) in tab-key-nav order.

And the last item you saw, the one you arrow-key'ed to get to, "sticks" when the
tab takes focus to the next input.  You don't "lose data", have to back up, and
hit Enter after re-arrowing.  I had to do that repeatedly in Message Filters.

Oh, and Filter title ought to default to folder name when filtering to a folder
;-).  I know, file another bug -- I'll get to it.

/be
xpfe (including mailnews) as of 10/01 (classic theme) works the other way
(tabbing out selects most widgets), this is certainly expected behavior on
windows although i'll accept that aviary is allowed to do whatever it likes.

stephend /thinks/ that this is still the case in 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041011
modern theme

brendan: did you mean thunderbird?
Target Milestone: mozilla1.8alpha4 → ---
Yes, I was using Thunderbird but filed against MailNews / Filters, thinking this
was not toolkit-dependent.

Correct me if I'm wrong: not only Windows, but Mac and all the Unix GUIs I have
dealt with all leave the current menu item selected when you tab out of a popup.
 It just don't seem right to do otherwise!

/be
please retest or move the bug to that other product. i'm perfectly happy with
the behavior xpfe has and am just amused by your disappointment in toolkit.

my mac is waiting for me to buy 4gb of ram so i can use it. certainly this bug
is yet another reason for me not to consider using thunderbird anytime soon, but
then again i'm in no hurry.

i should note that the windows's run dialog keeps the completed command after
you tab from it. i just configure my mozillas to only do inline autocomplete so
i don't encounter that problem.
Timeless: drop the anti-Thunderbird attitude and save the sermons for IRC.  I'm
reporting a bug.  If it needs to get moved to a different Product, that can
happen, but there's no need to spout off here.  If you don't like something, do
not use it.

Moving to Thunderbird until someone tells me about a better product (Asa, did
you make a New Toolkit component in Browser?).

/be
Component: Filters → General
Product: MailNews → Thunderbird
Summary: Message Filters dialog not keyboard-navigable (accessibility) → menu kbd navigation in Message Filters (and other places) seems wrong
Version: Trunk → unspecified
Windows 2000 mouse behaviour is somewhat weird: for a combobox the item that
gets selected is the one that received the mouse down event, even if you drag
the mouse to another item or completely off the dropdown. Its keyboard behaviour
is simply to fire a change event on any movement (as if the menulist wasn't
dropped down - this features in the latest SeaMonkey trunk).
Also note that we've recently improved XUL menulist keyboard access by allowing
you to use arrow keys or to type the option you want without opening it first.
QA Contact: general
is this still an issue on linux TB?   (and if I read this correctly _not_ on windows)
Yes this is still the case, but it's not tb specific. Moving to a possibly better component.
Assignee: bienvenu → nobody
Component: General → XUL Widgets
Product: Thunderbird → Toolkit
QA Contact: general → xul.widgets
But is it really linux only? Can't test atm, bug 399855 should be the same thing for windows.
(In reply to comment #12)
> But is it really linux only? Can't test atm, bug 399855 should be the same
> thing for windows.
Well first off: In other non-Gecko apps, e. g. Windows XP Control Panel applets, selecting an item with the Arrow keys and tabbing away from the combobox leaves the last focused item selected, like Brendan describes for web page select @size="1" elements. This would sound like this is also what Brendan would want for Linux.

On Mac, the situation is slightly different. select @size="1" or similar items in XUL are "menupopup" buttons: You hit the button, a menu appears, and from there you select using Enter, like in a regular menu. Comboboxes on the Mac are a little different since they are more like edit combos: You can select from a set of predefined values or type in something. So I think what we're talking about in terms of the filter list is a menu button (a fixed set of selections).
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.