Some interesting data:

 * If I click the first item, it becomes selected and focused.  Cool.
 * If I then click the second item, it also becomes selected and focused.  Also cool.  But the first item stays selected but loses focus.  Weird.
 * If I select the third item now, it also becomes selected and focused, and the other two menu items stay selected.  Very not cool.

This is the same behaviour in ./menustrip_openfiledialog.py with the "File" Menu Bar (using New and Open items), but it is not with the Menu/Menu Items in ./combobox_dropdown.py.

So I don't see the focus problems here, but I will fix the selection problems.

Fixed in r121464.

Hi Brad,

I tried in trunk r121505 and still could reproduced this bug without saw focused state when I done Click action. otherwise moved my mouse to the button in GUI window。 also both menu role have "selected" state from accerciser. 

please try this step:
(1)running samples/toolstripdropdownbutton.py
(2)running below pyatspi scrip
#!/usr/bin/env python

import pyatspi
import time

reg = pyatspi.Registry
desktop = reg.getDesktop(0)
ipy = pyatspi.findDescendant(desktop, lambda x: x.name == 'ipy' and x.getRoleName() == 'application')
menus = pyatspi.findAllDescendants(ipy, lambda x: x.getRoleName() == 'menu')

#click ToolStripDropDownButton1
menus[0].queryAction().doAction(0)

print "click ToolstripDropDownButton1 menus[0]:%s, menus[1]: %s"  % (menus[0].getState().getStates(), menus[1].getState().getStates())

#click ToolStripDropDownButton2
menus[1].queryAction().doAction(0)

print "click ToolstripDropDownButton2 menus[0]:%s, menus[1]: %s"  % (menus[0].getState().getStates(), menus[1].getState().getStates())



there is no "focused", I didn't saw duplicate "selected" from result by running pyatspi scrip, the "selected" always on menus[0], but I saw the duplication from accerciser, very weird. I can understand why there are two selected because do "click" action for menus[0] and menus[1] would open both of the menus that is different from gtk.menu. please take a look again, thanks :)

click ToolstripDropDownButton1:
menus[0]:[STATE_ENABLED, STATE_SELECTABLE, STATE_SELECTED, STATE_SENSITIVE, STATE_SHOWING, STATE_VISIBLE], 
menus[1]: [STATE_ENABLED, STATE_SELECTABLE, STATE_SENSITIVE, STATE_SHOWING, STATE_VISIBLE]

click ToolstripDropDownButton2:
menus[1]:[STATE_ENABLED, STATE_SELECTABLE, STATE_SENSITIVE, STATE_SHOWING, STATE_VISIBLE], 
menus[0]: [STATE_ENABLED, STATE_SELECTABLE, STATE_SELECTED, STATE_SENSITIVE, STATE_SHOWING, STATE_VISIBLE]

Calen, you're absolutely right about the focus issue.  I was clicking with my mouse and saw that Focus was there.  Fixing now...

I have a fix pending http://paste2.org/p/116360 going into SWF.

This should be fixed in r121535.  You'll need mono >= r121534 for the fix to work.

Hi Brad, sorry I need reopen this bug again, focus issue made me mad :(

(1)in trunk r121576, after click ToolstripDropDownButton2 by running pyatspi script in comment#4 or mouse click ToolstripDropDownButton2 by running below pyatspi script, both menu with "focused" state, but I think we only can focus one widget once time, for example, clicking ToolstripDropDownButton2 should rise "focused" for menu[1] but menu[0] should get rid of "focused":

click ToolstripDropDownButton1 :
menus[0]:[STATE_ENABLED, STATE_FOCUSED, STATE_SELECTABLE, STATE_SELECTED, STATE_SENSITIVE, STATE_SHOWING, STATE_VISIBLE], 
menus[1]: [STATE_ENABLED, STATE_SELECTABLE, STATE_SENSITIVE, STATE_SHOWING, STATE_VISIBLE]

click ToolstripDropDownButton2 :
menus[1]:[STATE_ENABLED, STATE_FOCUSED, STATE_SELECTABLE, STATE_SELECTED, STATE_SENSITIVE, STATE_SHOWING, STATE_VISIBLE], 
menus[0]: [STATE_ENABLED, STATE_FOCUSED, STATE_SELECTABLE, STATE_SELECTED, STATE_SENSITIVE, STATE_SHOWING, STATE_VISIBLE]


#!/usr/bin/env python

import pyatspi
import time

reg = pyatspi.Registry
desktop = reg.getDesktop(0)
ipy = pyatspi.findDescendant(desktop, lambda x: x.name == 'ipy' and x.getRoleName() == 'application')
menus = pyatspi.findAllDescendants(ipy, lambda x: x.getRoleName() == 'menu')

#move to ToolStripDropDownButton1

extents = menus[0].queryComponent().getExtents(pyatspi.DESKTOP_COORDS)
x = extents.x + (extents.width / 2)
y = extents.y + (extents.height / 2)

pyatspi.Registry.generateMouseEvent(x, y, 'b1c')
time.sleep(5)
print "click ToolstripDropDownButton1 menus[0]:%s, menus[1]: %s"  % (menus[0].getState().getStates(), menus[1].getState().getStates())

time.sleep(5)

#move to ToolStripDropDownButton2

extents1 = menus[1].queryComponent().getExtents(pyatspi.DESKTOP_COORDS)
x = extents1.x + (extents.width / 2)
y = extents1.y + (extents.height / 2)

pyatspi.Registry.generateMouseEvent(x, y, 'b1c')
time.sleep(5)
print "click ToolstripDropDownButton2 menus[1]:%s, menus[0]: %s"  % (menus[1].getState().getStates(), menus[0].getState().getStates())
##############


mouse click ToolstripDropDownButton1 :
menus[0]:[STATE_ENABLED, STATE_FOCUSED, STATE_SELECTABLE, STATE_SELECTED, STATE_SENSITIVE, STATE_SHOWING, STATE_VISIBLE], 
menus[1]: [STATE_ENABLED, STATE_SELECTABLE, STATE_SENSITIVE, STATE_SHOWING, STATE_VISIBLE]

mouse click ToolstripDropDownButton2 :
menus[1]:[STATE_ENABLED, STATE_FOCUSED, STATE_SELECTABLE, STATE_SELECTED, STATE_SENSITIVE, STATE_SHOWING, STATE_VISIBLE], 
menus[0]: [STATE_ENABLED, STATE_FOCUSED, STATE_SELECTABLE, STATE_SELECTED, STATE_SENSITIVE, STATE_SHOWING, STATE_VISIBLE]

This appears to be a SWF bug in that UIASelectionChanged isn't raised (and item.Selected is unchanged) when a ToolStripDrownDownButton loses selection.

Ignore comment #9.  I've got this figured out now:

It appears that in Vista, direct descendants of ToolStrip are not actually keyboard focusable.  We're doing this correctly in the provider, but the Bridge isn't so smart, and this is why you're seeing weird/inconsistent behavior.

The fix is to make sure that these controls are never keyboard focusable, and never report STATE_FOCUSED or STATE_FOCUSABLE.  Sorry to send everyone on such a wild goose chase.

I've updated the Bridge specification to make sure this is clear.

This is now fixed in r122251.

Closed in trunk r122387: "menu" without STATE_FOCUSED and STATE_FOCUSABLE.

sorry, I am still confused by "KeyLeft/Right to hover if parent: +Selected, +Focus" which is mentioned under "30. MenuItem" in our Bridge_Functional_Specification(as you wrote ToolStripDropDownButton Actions Inherits MenuItem). does that means mouse click menu1 then press Right may rise "selected" and "focused"? the fact is when I click menu1 I can use keyTab/Left/Right to move *focus to menu2. so do you think "focused" is required after do "click" action for menu? thanks!

I'm mildly confused by this part of the spec also.  (N.B.: I didn't write it)  Here's what I think it means:

If the menu item (or ToolStripDropDownButton) is a parent (e.g.: top level, no menu higher than it), you can use the left and right arrows to navigate to other top level menus.  In this case you see +Selected, but not +Focused as ToolStrip* controls can't receive focus.

Does this help you?

I still have a question, if ToolStripDropDownButton can't receive focus why when mouse click menu1 then i can use keyboard Right move to menu2, does that means it request "focued" state if can use keyboard(tab/right/left/up/down) to move focus??

i have tried using orca to navigate toolstripdropdownbutton.py, orca can't speak "toolstripdropdownbutton2" because without "focused" states if i mouse click menu1 then press key right move to menu2, so it is unknown focus in which menu.

after i tried some gtk menu(gedit, samples/gtkmenubar.py) with orca, i think "focused" state is important when *click or press right/left to move focus. 

how do you think? :)

Hey Calen,

Of course I think Focused is crucial, and without having that state, you're correct, Orca can't navigate to the control, but unfortunately Winforms doesn't support focus on ToolStripItem subclasses (e.g.: ToolStripDropDownButton) so our hands are tied.  You can verify this inside of Vista -- just create a window with only a ToolStrip and various ToolStripItems inside.  Now, try to tab to it.  You can't, because this control is not focusable.  Additionally, try to focus using UI Spy.  I can't begin to understand why they made this decision, but we have to duplicate it to be compliant.

Closing as INVALID.  Feel free to reopen this if you have more questions.

Whoops.

I think this issue is return to original problem what is in Description. I would like to describe it again:

PROBLEM STATEMENT

"menu" in toolstripdropdownbutton and in gtk.menubar show different states when
do click action

REPRO:

1. run accerciser
2. run uia2atk/test/samples/toolstripdropdownbutton.py
3. run uia2atk/test/samples/gtkmanubar.py
4. in accerciser, expand 'ipy' on the left tree, select item which is with
"menu" role, do "click" action under "interface viewer" for both Gtk and SWF
example to see menu's states

RESULTS:

in gtk.menubar(samples/gtkmenubar.py), do click action for menu role would rise
"focused" and "selected", but in swf.toolstripdropdownbutton do click action
for menu just rise "selected". 

EXPECTED RESULTS:

my expectation is like this:
    *"menu" role do Click to expand menu: +focused, +selected(same Gtk.Menu)
    *"menu" role do Click again to close menu: still focused,
-selected(same Gtk.Menu)

COMMENTS:

I have tried in Vista, using UISpy do "call method" in "Control Patterns" to expand menu can change HasKeyboardFocus to True for menu, here is the step:
(1)IronPython run toolstripdropdownbutton.py
(2)run UISpy, select menu item ToolStripDownDownButton2 in UISpy left tree
(3)right mouse click menu item ToolStripDownDownButton2 in UISpy left tree to select "Control Patterns"->click "Call method": you can see HasKeyboardFocus is changed to True

so I think when doing click action in accerciser also should rise "focused" state for that menu

I'd assert that Vista providing HasKeyboardFocus = True is actually a bug on their end.  The fact is, the control _doesn't_ have focus because you can't tab or arrow around once you obtain this focus.  Additionally, IsKeyboardFocusable = False, so you shouldn't have focus ever.

Closing.

Created attachment 296154 [details]
test script

hi I add more print info in Calen's test script, 
do:
(1)running samples/toolstripdropdownbutton.py
(2)running bug457990

the output info is:
"
click ToolstripDropDownButton1
 
menus[0]:[STATE_ENABLED, STATE_FOCUSED, STATE_SELECTABLE, STATE_SENSITIVE, STATE_SHOWING, STATE_VISIBLE]

menus[1]: [STATE_ENABLED, STATE_FOCUSABLE, STATE_SELECTABLE, STATE_SENSITIVE, STATE_SHOWING, STATE_VISIBLE]

 menus_items[0]:[STATE_ENABLED, STATE_FOCUSABLE, STATE_SELECTABLE, STATE_SELECTED, STATE_SENSITIVE, STATE_SHOWING, STATE_VISIBLE]
 
 menus_items[1]:[STATE_ENABLED, STATE_FOCUSABLE, STATE_SELECTABLE, STATE_SENSITIVE, STATE_SHOWING, STATE_VISIBLE]
 
 menus_items[2]:[STATE_ENABLED, STATE_FOCUSABLE, STATE_SELECTABLE, STATE_SENSITIVE, STATE_SHOWING, STATE_VISIBLE]
 
click ToolstripDropDownButton1 

menus[0]:[STATE_ENABLED, STATE_FOCUSED, STATE_SELECTABLE, STATE_SENSITIVE, STATE_SHOWING, STATE_VISIBLE]

menus[1]: [STATE_ENABLED, STATE_FOCUSABLE, STATE_SELECTABLE, STATE_SENSITIVE, STATE_SHOWING, STATE_VISIBLE]

menus_items[3]:[STATE_ENABLED, STATE_FOCUSABLE, STATE_SELECTABLE, STATE_SENSITIVE, STATE_SHOWING, STATE_VISIBLE]
 
menus_items[4]:[STATE_ENABLED, STATE_FOCUSABLE, STATE_SELECTABLE, STATE_SELECTED, STATE_SENSITIVE, STATE_SHOWING, STATE_VISIBLE]
 
menus_items[5]:[STATE_ENABLED, STATE_FOCUSABLE, STATE_SELECTABLE, STATE_SENSITIVE, STATE_SHOWING, STATE_VISIBLE]"


when click ToolstripDropDownButton1( menus[0]),  menus_items[0] is selected.

when click ToolstripDropDownButton2( menus[1]),  menus_items[4] is selected.

the circumstance is similar to bug 508967, I will close this bug and we should focus on that bug.

please see Comment #2 in bug 502972 that is the final solution.