404576 - Menus not available through AT-SPI Action:doAction

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Steve Lee]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007111904 Minefield/3.0b2pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007111904 Minefield/3.0b2pre

Menus can't be opened using the atspi Action interface, even though they correctly expose it.

Reproducible: Always

Steps to Reproduce:
1.run Minefield & Accerciser
2.navigate down to the file menu item (in first toolbar, path = 1 14 0 0
3.open Action interface in Interface Viewer
4.select click, and Perform Action
Actual Results:  
Nothing

Expected Results:  
Menu pops up

The menu appears a child elements of the menu but should appear in the popup window.

For comparison Gail also has them as static children in the main tree as well as in the popup. I don't know if this is by design, but may be is as the menu disappears on any system focus/activation event which is mostly mouse for key actions (I'm using switch input which doesn't cause this).

Toolbars work fine

Comment 1

[Ginn Chen]

nsXULElement::Click() is called, but it doesn't invoke nsMenuFrame::HandleEvent().

Comment 2

[Steve Lee]

Hi Ginn, I've been trying to work on a patch but I still have more questions than answers as only using code inspection with crashes and Mozilla is so new to me.

I can see that I can simulate mouse clicks with HandleEvent once I get the right nsMenuFrame (can't see how exactly, but think I can can get the nsIPresShell, which is on the way). Any hints appreciated.

However AFAIKS the call to DoCommand in XULMenu passes a NULL aContent (default param) so the mDOMNode is used which looks incorrect for Chrome.

Then content is assigned an instance of nsQueryInterface with do_QueryInstance, yet the object and NOT it's address is passed as the timer closure and the callback then treats it as a nsIContent *. nsQueryInterface only defines operator (), so I can't see any implicit conversions. 

It seems to me this is dangerous as you are relying on the object's internal layout (it's sole member is a pointer) when doing the old style void* cast and then treating that as a pointer to something else. Or is this a common idiom in 
Mozilla?

What am I missing? Am I getting too rusty with c++ after python?

Comment 3

[Steve Lee]

Just bumping this

Comment 4

[Marco Zehe (:MarcoZ)]

The patch that's currently in bug 410765 also fixes this bug.

Comment 5

[alexander :surkov (:asurkov)]

fixed per comment #4

Comment 6

[Steve Lee]

confirmed WFM