Bug 471411

Summary: ToolStripDropDownButton: selection doesn't rise focused state for menu items
Product: [Mono] UI Automation Reporter: calen chen <cachen>
Component: Winforms - GeneralAssignee: E-mail List <mono-a11y-bugs>
Status: VERIFIED FIXED QA Contact: E-mail List <mono-a11y-qa>
Severity: Normal    
Priority: P3 - Medium    
Version: Release 0.9   
Target Milestone: ---   
Hardware: x86   
OS: openSUSE 11.0   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Bug Depends on: 474634    
Bug Blocks:    

Description calen chen 2009-02-02 07:30:54 UTC
PROBLEM STATEMENT

in accerciser under "interface viewer", do Selection for Menu doesn't rise "focused" state for selected menu item


REPRO:

1. run accerciser
2. run uia2atk/test/samples/toolstripdropdownbutton.py
3. in accerciser, select 'ToolStripDropDownButton1' on the left tree, under "interface viewer" in Selection box, click "Blue" item
4. in accerciser, expand 'ToolStripDropDownButton1' on the left tree, select
Blue item which is with "menu item" role, see Blue item's states

RESULTS:

after doing step 3, in step 4 Blue menu item doesn't rise focused state

EXPECTED RESULTS:

my expectation is like this:
    *select menu item from Selection box under "interface viewer" for "Menu", which selected menuitem: +focused +selected(same Gtk.Menu(samples/gtkmenubar.py))

so I think after doing step 3, in step4 Blue item should rise "focused" and "selected" both

COMMENTS:
Comment 1 Brad Taylor 2009-02-11 21:03:29 UTC
Calen, I disagree that we should be setting Focused or Selected after the menu is already hidden.  Focused should only be set if the widget currently has focus, e.g.: focus lines drawn around the control and the ability to tab/up/down to other nearby controls.  Likewise, the same should be said about Selected.  Checking with the Gtk sample, it confirms my feelings by removing Selected and Focused when the parent menu is hidden.  All that said, we don't do it correctly yet, so I'll use this bug to clean up visible/showing and remove Selected.

Additionally, this bug heavily depends on #474634, so it's probably best to wait until it is complete.
Comment 2 calen chen 2009-02-12 03:26:55 UTC
Hi Brad, now the difference is: 
Gtk sample rise Focused and Selected when doing *SelectChild from accerciser (the menu also is hidden), then click Menu from Gui, you may see the selected MenuItem covered with blue background that means this MenuItem is selected and focused. after that doing *ClearSelection from accerciser, you may see there is no MenuItem covered with blue background from Gui, also the previous selected MenuItem get rid of "selected" and "focused" states

but do the same *SelectChild action in SWF sample the selected MenuItem doesn't exactly be selected and focused(never covered with blue background), it looks like *SelectChild and *ClearSelection actions are unuseful, maybe there are something different implementation between Gtk and Swf control I didn't know, do you think we need do some job to deal with *SelectChild *ClearSelection action?
Comment 3 Brad Taylor 2009-02-18 15:00:57 UTC
I don't know if Gtk/GAIL's behavior makes sense here.  Focused means (to me) that that control has keyboard focus, and in this case, it doesn't.  However, I'll consult with others, and see what they say.
Comment 4 Brad Taylor 2009-02-18 15:20:48 UTC
07:10 <@mgorse> brad: So it isn't like a normal menu and isn't accessible 
                through the keyboard?
07:10 <@brad> basically, it's a button that when clicked drops down a menu
07:10 <@brad> and since it's in the toolstrip, it's not keyboard accessible
07:10 <@brad> I don't know why they do this
07:11 <@mgorse> Yeah, I don't think that setting Focused makes sense then.  The 
                atk header says that that state "indicates this object 
                currently has the keyboard focus"
07:11 <@brad> what about selected?
07:14 <@mgorse> brad: I think that setting it makes sense when the menu isn't 
                hidden
07:15 <@brad> mgorse: that's what I thought too.  thanks for your help.
Comment 5 Brad Taylor 2009-02-18 15:42:44 UTC
There is one bug I see though:

1. Open Accerciser
2. Run uia2atk/test/samples/toolstripdropdownbutton.py
3. In accerciser, expand 'ToolStripDropDownButton1' in the tree view on the left to reveal Red, Blue and Green menu items. 
4. Select the Red menu item.
4. On the Interface Viewer tab, expand the Accessible area.
5. Using your mouse, navigate to the ToolStripDropDownButton window and click on ToolStripDropDownButton1.  Click on the Red item.
6. The Focused state remains in the list, and this is incorrect since keyboard focus no longer exists.

I've gone ahead and fixed this in r127281.

Hopefully all of this makes sense Calen.  If you have any questions, let's discuss this over email instead of adding more traffic to this bug.
Comment 6 calen chen 2009-03-04 04:06:29 UTC
Closed in rpm version:

uiautomationwinforms-128049-610
uiaatkbridge-128019-585
mono-uia-128117-258