Happens most of the time, but not always. Str: 1. Open Firefox. 2. Press alt+v to activate the View menu. 3. Press t to activate the Toolbars sub-menu. Expected: A menuStart event should be fired for the "Toolbars" menu, followed by a focus event for the "Menu Bar" menu item (the focused item). Actual: A focus event for the "Menu Bar" menu item (the focused item) is fired, followed by a menuStart event for the "Toolbars" menu.

cannot reproduce it, menustart event is fired and then focus event. But it sounds like notifications to a11y are not in sync so the result can be intermittent (events/test_menu.xul confirms this). Jamie, how is bad this for NVDA?

For screen readers, menuStart is basically equivalent to focus. Therefore, when this occurs, it looks to NVDA like another menu got focus after the menu item got focus, so if you ask NVDA to report the current focus, it reports the menu instead of the menu item.

For my approach to fixing this bug I was advised to make a menuPopupOpen() and menuPopupClose() in /dom/base/nsFocusManager.cpp. Open() would basically change the focus to the opened submenu, while close would go the opposite way. At the moment I am stuck because I am still trying to understand what I can do with each class / methods in the class. It would be nice to know where to procede.

So what notifications (DOM events) do we use right now to report the focus change and what notifications will be replaced by new methods?

As it sits, nsFocusManager::NotifyFocusStateChange is the only method we have found that adds an nsEventStates to the element in the content.  We noticed that it defaults the event state as NS_EVENT_STATE_FOCUS.  Also we looked into the calls to NotifyFocusStateChange and the bool value of aGettingFocus is always hard coded. As for the second question, the design that we proposed was given to us by tbsaunde, and we're not exactly sure what notifications would be replaced.

(In reply to Jenny from comment #5) > As it sits, nsFocusManager::NotifyFocusStateChange is the only method we > have found that adds an nsEventStates to the element in the content.  We > noticed that it defaults the event state as NS_EVENT_STATE_FOCUS.  It seems you look at wrong code, menus aren't subject of DOM focus events so nsFocusManager is not responsible for that. You should look at mozilla::a11y::FocusManager to answer my question (and nsRootAccessible where DOM events area handled that we use to fire accessible focus event). > As for the second question, the design that we proposed was given to us by > tbsaunde, and we're not exactly sure what notifications would be replaced. I'd say it makes sense to understand how it works before working on implementation

> It seems you look at wrong code, menus aren't subject of DOM focus events so > nsFocusManager is not responsible for that. You should look at > mozilla::a11y::FocusManager to answer my question (and nsRootAccessible > where DOM events area handled that we use to fire accessible focus event). > looking at the mozilla::a11y::FocusManager I see a set of methods dedicated to focus notifications and processing, specifically NotifyOfDomFocus, ActiveItemChanged, ProcessDomFocus, ProcessFocusEvent. Also in the nsRootAccessible, there is a ProcessDomEvent method. Is this what you are talking about?

(In reply to Jenny from comment #7) > > It seems you look at wrong code, menus aren't subject of DOM focus events so > > nsFocusManager is not responsible for that. You should look at > > mozilla::a11y::FocusManager to answer my question (and nsRootAccessible > > where DOM events area handled that we use to fire accessible focus event). > > > > looking at the mozilla::a11y::FocusManager I see a set of methods dedicated > to focus notifications and processing, specifically NotifyOfDomFocus, > ActiveItemChanged, ProcessDomFocus, ProcessFocusEvent. Also in the > nsRootAccessible, there is a ProcessDomEvent method. Is this what you are > talking about? well, to answer Alex's question you should look at what causes them to be called, although reading them may provide some useful context.

(In reply to Trevor Saunders (:tbsaunde) from comment #8) > well, to answer Alex's question you should look at what causes them to be > called, although reading them may provide some useful context. So we should be looking at the methods being called and the parameter being the menu bar? If this is the case, would it be helpful to trace the call stack while the menu is being opened? If so, is there any addons that you would recommend to do this?

(In reply to Daniel from comment #9) > So we should be looking at the methods being called and the parameter being > the menu bar? > If this is the case, would it be helpful to trace the call stack while the > menu is being opened? yes > If so, is there any addons that you would recommend to > do this? just set break point

or you could enable A11YDEBUG_FOCUS ifdef (see FocusManager.h) so all focus stuffs will be logged into console

(In reply to alexander :surkov from comment #11) > or you could enable A11YDEBUG_FOCUS ifdef (see FocusManager.h) so all focus > stuffs will be logged into console I have enabled it and have checked out the DOMi addon looking at all of it. My computer seems to be firing the focus even before the menu start event almost every single time, but when it is ending the event, everything is fired in order. I have tried this around 5 times, and it has happened for around 75% of the time.