When navigating in an HTML combo box or list using the arrow keys, each time the selection changes, there is a focus event as well as a state-changed:focused event for the menu/list item which received focus. Both of these events are absent when jumping to an item using first letter navigation. Steps to reproduce: 1. Launch Accerciser and turn on event monitoring 2. Bring up the page to enter a new bug 3. Move focus to the OS combo box and press W to move among items that begin with "W" 4. Move focus to the version list and press P to move among the items that begin with "P"

We must be forgetting to fire a DOMMenuitemActive event somewhere in nsListControlFrame.cpp

Hi Mats, we just need this events fired.

Comment on attachment 268256 [details] [diff] [review] 1 line patch I noticed a strange thing that happens occasionally with this patch: STEPS TO REPRODUCE 1. focus the "Product" combobox on a Bugzilla bug 2. there are a few products that starts with M, try jumping between those by typing: 'm' <pause1> 'a' <pause2> 'm' <pause1> 'o' <pause2> 'm' <pause1> 'i' <pause2> <pause1> needs to be less than a second <pause2> needs to be more than a second (It doesn't work very well, but that's not my point) Every now and then the combobox seems to lose focus and the page is scrolled to the end and the AT starts reading "Actions: ..." from the footer. I can only trigger that bug with this patch, but I don't really see how this patch could cause it either... maybe it's some timing thing, or event order... When this occurs I get a bunch of warnings on the console as well: WARNING: not supported for frames: file nsFrame.cpp, line 547 WARNING: not supported for frames: file nsFrame.cpp, line 547 WARNING: not supported for frames: file nsFrame.cpp, line 547 WARNING: not supported for frames: file nsFrame.cpp, line 547 WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed: file nsAccessibleWrap.cpp, line 727 WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed: file nsAccessibleWrap.cpp, line 727 ... The patch looks good, but please file a bug on the above unless you want to investigate it here. r=mats

Mats, which AT are you using? The AT's all manage focus differently, and some have modes where they don't manage focus. For example, in some AT's pressing some letters (such as 'h') initiates a navigation command (such as next heading)

Orca on Linux (Ubuntu-feisty)

Mats, first letter navigation is something I'm just now implementing. That's how I discovered we weren't getting events. :-) What you are seeing is Orca's structural navigation kicking in when it shouldn't be. (O is moving you to the next "large object"; M doesn't have an associated object type)

Should the FireMenuItemActiveEvent() be inside #ifdef ACCESSIBILITY #endif

I made that change with the bustage fix checkin.