Bug 443971 - HasKeyboardFocus incorrectly raised when hovering a parent menu item
Summary: HasKeyboardFocus incorrectly raised when hovering a parent menu item
Status: RESOLVED FIXED
Alias: None
Product: UI Automation
Classification: Mono
Component: Winforms - UIA (show other bugs)
Version: Unspecified
Hardware: Other Other
: P3 - Medium : Normal
Target Milestone: Release 1.0
Assignee: Sanford Armstrong
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 428533
  Show dependency treegraph
 
Reported: 2008-11-11 22:36 UTC by Andres Aragoneses
Modified: 2008-12-15 17:26 UTC (History)
0 users

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andres Aragoneses 2008-11-11 22:36:38 UTC
A top parent menu item (File, not Open; Help, not About), I shouldn't get any KeyboardFocus signal when the mouse hovers, but I get this from the provider:
RaiseAutomationPropertyChangedEvent(AutomationElementIdentifiers.HasKeyboardFocusProperty),
which I shouldn't get.

Sandy: assign it to you if you finish it today. If not, just let's carry it over in next iteration. Thanks!
Comment 1 Sanford Armstrong 2008-11-12 10:51:32 UTC
There are two things to fix here:

1) Return false for this property if the TSItem is not a "leaf" menu item or if it is a top parent item as Andres describes.

2) (Probably need to) Add internal SWF event to detect additional situations where keyboard focus changes.  Currently only checking on mouse enter/leave because that is all that seems to be available.

I'll take this next iteration.
Comment 2 Andres Aragoneses 2008-11-12 20:55:53 UTC
(In reply to comment #1 from Sanford Armstrong)
> There are two things to fix here:
> 
> 1) Return false for this property if the TSItem is not a "leaf" menu item or if
> it is a top parent item as Andres describes.
> 
> 2) (Probably need to) Add internal SWF event to detect additional situations
> where keyboard focus changes.  Currently only checking on mouse enter/leave
> because that is all that seems to be available.

Why not listening to a different property and thus not raising it (rather than raising it false)? Look at a recent mgorse's commit:

--- trunk/uia2atk/src/UIAutomationWinforms/UIAutomationWinforms/Mono.UIAutomation.Winforms.Events/ListBox/ListItemAutomationHasKeyboardFocusPropertyEvent.cs	2008-11-12 02:04:21 UTC (rev 118572)
+++ trunk/uia2atk/src/UIAutomationWinforms/UIAutomationWinforms/Mono.UIAutomation.Winforms.Events/ListBox/ListItemAutomationHasKeyboardFocusPropertyEvent.cs	2008-11-12 02:39:52 UTC (rev 118573)
@@ -49,21 +49,21 @@
 	
 		public override void Connect ()
 		{
-			((SWF.ListBox) Provider.Control).SelectedIndexChanged 
-				+= new EventHandler (OnSelectedIndexChanged);
+			((SWF.ListBox) Provider.Control).UIAFocusedItemChanged 
+				+= new EventHandler (OnUIAFocusedItemChanged);
 		}

...

Modified: trunk/uia2atk/src/UIAutomationWinforms/UIAutomationWinforms/ChangeLog
===================================================================
--- trunk/uia2atk/src/UIAutomationWinforms/UIAutomationWinforms/ChangeLog	2008-11-12 02:04:21 UTC (rev 118572)
+++ trunk/uia2atk/src/UIAutomationWinforms/UIAutomationWinforms/ChangeLog	2008-11-12 02:39:52 UTC (rev 118573)
@@ -1,3 +1,20 @@
+2008-11-11  Mike Gorse  <mgorse@novell.com>
+
+	* Mono.UIAutomation.Winforms/ListViewProvider.cs: For
+	  HasKeyboardFocusProperty, use focused item rather than the
+	  selected item.


Does it make sense?

Raising priority.
Comment 3 Andres Aragoneses 2008-11-12 20:56:33 UTC
(In reply to comment #1 from Sanford Armstrong)
>
> I'll take this next iteration.
> 

Mmm, you forgot to assign and estimate?
Comment 4 Sanford Armstrong 2008-11-12 21:52:08 UTC
(In reply to comment #3 from Andrés G. Aragoneses)
> (In reply to comment #1 from Sanford Armstrong)
> >
> > I'll take this next iteration.
> > 
> 
> Mmm, you forgot to assign and estimate?

Whoops, this is because it wasn't targetted for 0.9.  I can fix part of it for 0.9, but it's too late to get changes into MWF, so we won't have the best even coverage in all likeliness.

But I can at least return the correct value! :-)

Targetting for 0.9 and adding hours, and assigning to me.
Comment 5 Sanford Armstrong 2008-11-13 02:03:38 UTC
I meant to say "won't have the best *event* coverage", in case that typo wasn't obvious.
Comment 6 Sanford Armstrong 2008-11-13 02:04:32 UTC
Updating hours.
Comment 7 Sanford Armstrong 2008-11-14 04:30:45 UTC
Committed partial fix (only true for nodes that are leaf nodes and whose parent is another menu item, not the menu/strip itself). Still work to do on this.
Comment 8 Sanford Armstrong 2008-11-20 20:26:48 UTC
Dropping to P3 and pushing to 1.0.  The only thing left to do on this bug is to add internal events to MWF, and that won't happen for 0.9.

Andres, I believe the only reason this was P1 was because of the bad values being returned, correct?  Since that should be fixed, I'm dropping the priority.  Let me know if this is incorrect.
Comment 9 Andres Aragoneses 2008-11-20 21:23:25 UTC
Mario will look at this for now. Thanks for helping Mario.
Comment 10 Sanford Armstrong 2008-12-15 17:26:20 UTC
The rest of the fixes for this bug should be fixed as part of bug #457990.  Closing this one as resolved, because the bug described in the summary was fixed.