I am a little confused about this.  It is true that Gtk doesn't have a "focusable" state on Menus and MenuItems, Gtk MenuItems do get the "focused" state when the mouse is hovering over them or when they have keyboard focus.  So, is the bug that Gtk 1) that Gtk MenuItems should have the focusable state, 2) that Gtk MenuItems should not get the focused state or 3) this bug (i.e., WinForms MenuItems should not have the focusable state).

It is also worth noting that currently the highest level ToolStripMenuItem (i.e., the ToolStripMenuItem with no other menu parents) does not have the focusable state, even though it has the "menu" role.  For example, in the menustrip.py sample, the "New" menu under "File" has the "focusable" state, but the "File" menu does not, despite both of the accessibles having the "menu" role.

Okay, after talking to Andrés, I think this bug is invalid.  Let me know what you think Ray?  Here is what I discovered:

(In reply to comment #1)
> I am a little confused about this.  It is true that Gtk doesn't have a
> "focusable" state on Menus and MenuItems, Gtk MenuItems do get the "focused"
> state when the mouse is hovering over them or when they have keyboard focus. 
> So, is the bug that Gtk 1) that Gtk MenuItems should have the focusable state,
> 2) that Gtk MenuItems should not get the focused state or 3) this bug (i.e.,
> WinForms MenuItems should not have the focusable state).
> 

<@bgmerrell> could someone provide some quick feedback to my 485515 comment?
<@knocte> bgmerrell: we decided on bugs#479397 and #485524 that we were not going to mimic some gail bugs
<@knocte> the references to the gail bugs are in those bugs

> It is also worth noting that currently the highest level ToolStripMenuItem
> (i.e., the ToolStripMenuItem with no other menu parents) does not have the
> focusable state, even though it has the "menu" role.  For example, in the
> menustrip.py sample, the "New" menu under "File" has the "focusable" state,
> but the "File" menu does not, despite both of the accessibles having the
> "menu" role.

Oops, I forgot about that the ToolStripDropDownButton bridge functional spec says "Does not have Focusable or Focused state if it is a direct descendant of a ToolStrip."  This will make some of our tests kind of confusing, but we'll just have to remember that.

(In reply to comment #2)

8< snip

> > It is also worth noting that currently the highest level ToolStripMenuItem
> > (i.e., the ToolStripMenuItem with no other menu parents) does not have the
> > focusable state, even though it has the "menu" role.  For example, in the
> > menustrip.py sample, the "New" menu under "File" has the "focusable" state,
> > but the "File" menu does not, despite both of the accessibles having the
> > "menu" role.
> 
> Oops, I forgot about that the ToolStripDropDownButton bridge functional spec
> says "Does not have Focusable or Focused state if it is a direct descendant of
> a ToolStrip."  This will make some of our tests kind of confusing, but we'll
> just have to remember that.

Double oops, that information is obviously about ToolStripDropDownButton not a ToolStripMenuItem.  So, I am still wondering if the highest level ToolStripMenuItems should have the focusable and focused states.  Once you have clicked on a ToolStripMenuItem that is a direct decendent of a ToolStrip you can use the keyboard to navigate to other ToolStripMenuItems.  This is very similar to the ToolStripDropDownButton, which I mentioned above, so maybe it will have the same condition of not having the focusable or focused state if it is a direct descendant of a ToolStrip.  What say you?

(In reply to comment #3)
> (In reply to comment #2)
> Double oops, that information is obviously about ToolStripDropDownButton not a
> ToolStripMenuItem.  So, I am still wondering if the highest level
> ToolStripMenuItems should have the focusable and focused states.  Once you have
> clicked on a ToolStripMenuItem that is a direct decendent of a ToolStrip you
> can use the keyboard to navigate to other ToolStripMenuItems.  This is very
> similar to the ToolStripDropDownButton, which I mentioned above, so maybe it
> will have the same condition of not having the focusable or focused state if it
> is a direct descendant of a ToolStrip.  What say you?

Sigh.. I am just making a mess here, sorry.  It turns out that ToolStripMenuItems that are direct descendants of a ToolStrip *do* have the "focusable" state.  It is ToolStripMenuItems that are direct descendants of MenuStrips that do not.  Does it make any sense for that to be the case?  You can use the toolstripmenuitem.py sample as an example.

great example, that makes a lot of sense. 
that means this bug is valid, right? but with regards to sandy's opinion, we'd better seperate the menuitem / toolstripmenuitem bugs. I have no idea what to do with this bug,

Hwy guy, anyone thinks this is a invalid bug? 
according to comment 4, i summarize as following for MainMenu;

MenuItems have "focusable"
Menus that are direct descendants of MainMenu that do NOT have "focusable", otherwise, Menus do have "focusable"

please comment thanks.

I think the bug is not valid, please see the comment 5 of bug 516151. I think the " menu, submenu, menu items" on "Mainmenu, Menusrip, ToolStripMenuItem ..." should have "focusable" and "selectable" state , and obviously can be focused and "selected" states, " menu, submenu, menu items " can be "selected" at the same time, but the "focused" state only cycles between them.

Ray, what do you think?

(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > Double oops, that information is obviously about ToolStripDropDownButton not a
> > ToolStripMenuItem.  So, I am still wondering if the highest level
> > ToolStripMenuItems should have the focusable and focused states.  Once you have
> > clicked on a ToolStripMenuItem that is a direct decendent of a ToolStrip you
> > can use the keyboard to navigate to other ToolStripMenuItems.  This is very
> > similar to the ToolStripDropDownButton, which I mentioned above, so maybe it
> > will have the same condition of not having the focusable or focused state if it
> > is a direct descendant of a ToolStrip.  What say you?
> 
> Sigh.. I am just making a mess here, sorry.  It turns out that
> ToolStripMenuItems that are direct descendants of a ToolStrip *do* have the
> "focusable" state.  It is ToolStripMenuItems that are direct descendants of
> MenuStrips that do not.  Does it make any sense for that to be the case?  You
> can use the toolstripmenuitem.py sample as an example.

I agree that the top-level ToolStripMenuItems that are direct descendants of a ToolStrip ('View' and 'Help' menu) should have "focusable" because perform <Alt>+V to open menu then we can use keyRight/Left to navigate focus between 'View' and 'Help' without droping menu down. 

But I am little confused you said ToolStripMenuItems that are direct descendants of MenuStrips that do not have "focusable", run toolstripmenuitem.py as example('File' and 'Edit' are descendants of MenuStrip), perform <Alt>+F to open menu then we also can use keyRight/Left to navigate focus between 'File' and 'Edit' without droping menu down.(according to bug516151 you have mentioned this condition:)). so I think the top-level ToolStripMenuItems that are direct descendants of MenuStrips('File' and 'Edit') also should have "focusable" state.

The top-level MainMenu maybe shouldn't have "focusable" state because when we perform <Alt>+File then press keyRight/Left, the focus always is navigated between the first menu_item with droping menu down. but if we mouse click menu 'File' to drop it down, the first menu_item doesn't fosued, when press keyDown the focus move to 'New', can it be say the focus originally is on 'File'? If yes, when mouse click the MainMenus that should raise 'focused' state, but no 'focusable' seems no harm

(In reply to comment #9)
> I agree that the top-level ToolStripMenuItems that are direct descendants of a
> ToolStrip ('View' and 'Help' menu) should have "focusable" because perform
> <Alt>+V to open menu then we can use keyRight/Left to navigate focus between
> 'View' and 'Help' without droping menu down. 
> 
> But I am little confused you said ToolStripMenuItems that are direct
> descendants of MenuStrips that do not have "focusable", run
> toolstripmenuitem.py as example('File' and 'Edit' are descendants of
> MenuStrip), perform <Alt>+F to open menu then we also can use keyRight/Left to
> navigate focus between 'File' and 'Edit' without droping menu down.(according
> to bug516151 you have mentioned this condition:)). so I think the top-level
> ToolStripMenuItems that are direct descendants of MenuStrips('File' and 'Edit')
> also should have "focusable" state.
> 
> The top-level MainMenu maybe shouldn't have "focusable" state because when we
> perform <Alt>+File then press keyRight/Left, the focus always is navigated
> between the first menu_item with droping menu down. but if we mouse click menu
> 'File' to drop it down, the first menu_item doesn't fosued, when press keyDown
> the focus move to 'New', can it be say the focus originally is on 'File'? If
> yes, when mouse click the MainMenus that should raise 'focused' state, but no
> 'focusable' seems no harm

I agree with Calen.

Let me summarize it here:
For MainMenu,
Top-level Menus: +/-focusable (should have or should not have, i prefer to have)
Menu Items: +focusable"

For MenuStrip:
Top-level Menus: +focusable
Toolstrip Menu Items: +focusable

(In reply to comment #9)

> The top-level MainMenu maybe shouldn't have "focusable" state because when we
> perform <Alt>+File then press keyRight/Left, the focus always is navigated
> between the first menu_item with droping menu down. but if we mouse click menu
> 'File' to drop it down, the first menu_item doesn't fosued, when press keyDown
> the focus move to 'New', can it be say the focus originally is on 'File'? If
> yes, when mouse click the MainMenus that should raise 'focused' state, but no
> 'focusable' seems no harm 

my opinion is :
1. the MainMenu should have 'focusable' state and can raise 'focused'. the "menu bar" in MainMenu and ToolStripMenuItem and MenuStrip should performed as one man. since the "menu bar" with menu , sub menu, menu item do the same performance in MenuStrip and ToolStripMenuItem, the MainMenu should does too.

2. the 'focusable' and 'focused' should appear at the same time

3. for the comment :
"when we perform <Alt>+File then press keyRight/Left, the focus always is navigated between the first menu_item with droping menu down" 

I think the focus can cycles between the top menus. Do the following REPRO:
a. perform "alt +f" on mainmenu samply.
b. press "Right" key , output: File
                                 New
                                 Open
                                 Exit
c. press "Right" key,  output: File
                                 New->Document
                                 Open
                                 Exit
d. press "Right" key,  output: Edit
                                 Undo
                                 Redo
e. Press "Right" key,  output: Help
                                 About
f. press "left" key, output:   Edit
                                 Undo
                                 Redo

(In reply to comment #10)

> I agree with Calen.
> 
> Let me summarize it here:
> For MainMenu,
> Top-level Menus: +/-focusable (should have or should not have, i prefer to
> have)
> Menu Items: +focusable"
> 
> For MenuStrip:
> Top-level Menus: +focusable
> Toolstrip Menu Items: +focusable

I think : 
For MainMenu,
Top-level Menus: +focusable 

hope we can get a coincident conclusion.

All: please take in account that MainMenu is a deprecated widget, which has been replaced by MenuStrip, so for the release we focused on the non-deprecated widget.

That being said, why some of you think it should behave differently as MenuStrip?

IMO this bug is just about making MainMenu (and its children) behave like a MenuStrip. If you don't agree, then first open a bug against MenuStrip and explain your reasonings there. Remember that this is not working exactly like Gtk/Gail because we found some bugs there (filed in BGO) so we tried not to have them in our impl (MenuStrip).

(In reply to comment #10)
> 
> I agree with Calen.
> 
> Let me summarize it here:
> For MainMenu,
> Top-level Menus: +/-focusable (should have or should not have, i prefer to
> have)
> Menu Items: +focusable"
> 
> For MenuStrip:
> Top-level Menus: +focusable
> Toolstrip Menu Items: +focusable

I also agree with this.  However, this bug is beginning to dovetail with "Bug 516151 - MainMenu: top-level menu accessibles should not have "focusable" state".  I am okay with marking Bug 516151 invalid, though, if we decide that a top-level MainMenu accessible should be focusable.  

Another thing to consider is that a mouse click or a click action on a MainMenu top-level menu, will apparently give the widget keyboard focus.  However, the top-level menu never appears to get the "focused" state right now, so we would have to log bugs for that if we do decide that it is focusable; there is no point making the accessible focusable if it is never focused :)

*** Bug 516151 has been marked as a duplicate of this bug. ***

(In reply to comment #13)
> All: please take in account that MainMenu is a deprecated widget, which has
> been replaced by MenuStrip, so for the release we focused on the non-deprecated
> widget.
> 
> That being said, why some of you think it should behave differently as
> MenuStrip?
> 
> IMO this bug is just about making MainMenu (and its children) behave like a
> MenuStrip. If you don't agree, then first open a bug against MenuStrip and
> explain your reasonings there. Remember that this is not working exactly like
> Gtk/Gail because we found some bugs there (filed in BGO) so we tried not to
> have them in our impl (MenuStrip).

I agree with Andres.since MainMenu is a deprecated widget, and menu uder munu bar in MenuStrip and ToolSripMenuItem have the same behavior and same problem(lack of 'focusable' but can be 'focused'), we should focus on that two widgets firstly.I will de-prioritize bugs about MainMenu widget.

(In reply to comment #14)

> Another thing to consider is that a mouse click or a click action on a MainMenu
> top-level menu, will apparently give the widget keyboard focus.  However, the
> top-level menu never appears to get the "focused" state right now, so we would
> have to log bugs for that if we do decide that it is focusable; there is no
> point making the accessible focusable if it is never focused :)

I log a bug:
Bug 519664 - MainMenu: top-level menu accessibles should receive "focused" state when dropped down