Re: [g-a-devel] Focus - AT vs. mouse/keyboard manipulation

[Bill Haneman <Bill Haneman Sun COM>]

On Mon, 2006-08-14 at 17:18, A Nagappan wrote:
> Hi Bill,
> 
>   Just fixed in CVS,


Hi Nagappan:

When you say "fixed in CVS", what code was modified?  Was metacity
changed?  A pointer to a bugzilla report with a patch would be super.  I
am a little surprised that this is working now, and am wondering how the
"grabFocus" call from inside an application is getting around the
metacity focus stealing prevention.

Thanks in advance,

Bill

>  you can test it with the following code:
> 
> from ldtputils import *
> from ldtp import *
> 
> launchapp ('gedit')
> grabfocus ('*-gedit')
> 
> Thanks
> Nagappan
> 
> Nagappan A <anagappan novell com>
> Linux Desktop Testing Project - http://ldtp.freedesktop.org
> http://nagappanal.blogspot.com
> 
> Novell, Inc.
> SUSE® Linux Enterprise 10
> Your Linux is ready™
> http://www.novell.com/linux
> 
> 
> >>> Bill Haneman <Bill Haneman Sun COM> 08/14/06 8:05 PM >>>
> On Mon, 2006-08-14 at 15:03, Nagappan wrote:
> > Hi Bill,
> > 
> > Test case is available here -
> > http://bugzilla.gnome.org/show_bug.cgi?id=347481
> 
> I don't think that's really a valid test case for the problem I was
> describing.
> 
> It's not clear to me that grabFocus() should work on a component in a
> window that isn't active.
> 
> regards
> 
> Bill
> 
> > 
> > Thanks
> > Nagappan
> > 
> > Bill Haneman wrote:
> > > (cross-posting to metacity-devel, because I don't know how to fix this
> > > and I suspect the metacity hackers will)
> > >
> > > Hi Zack;
> > >
> > > I think you're encountering several issues here.  With regard to the
> > > Action interface, items which aren't posted to the screen may still be
> > > activated.  For menu items this probably isn't really a problem, with
> > > respect to the desired effect for end users.
> > >
> > > For dialogs, I agree that there's a problem.  The difficulty you are
> > > seeing is probably a result of "focus stealing prevention" which was
> > > added to the metacity window manager (in the gnome-2.14 timeframe I
> > > think).  This behavioral change was intended to prevent applications
> > > from "stealing" focus except in response to a direct user action. 
> > > However, I believe that the AT-SPI Actions should probably be treated as
> > > "user" actions even though they are technically 'programmatic' ones.  I
> > > don't know whether new metacity or window-manager API would be required
> > > to make this work, or not.  For this reason I am cross-posting your
> > > message.
> > >
> > > Metacity folks: if an end-user of an assistive technology such as a
> > > screen reader or onscreen keyboard invokes the "activate" action on a
> > > button which opens a dialog, the desired behavior is for that dialog to
> > > take focus, since it is being posted in response to an end-user action
> > > (albeit indirectly).  I am happy to annotate the AT-SPI docs to warn
> > > clients of the API that they should not use the Action:doAction API
> > > except in response to direct end-user requests.
> > >
> > > Zack, a specific test case that we can use for diagnosis and discussion
> > > would help.  Do you have one in mind?
> > >
> > > Best regards,
> > >
> > > Bill
> > >
> > > On Wed, 2006-08-09 at 21:57, Zack Cerza wrote:
> > >   
> > >> Hi,
> > >>
> > >> If I do something that results in a dialog popping up via either the 
> > >> mouse or the keyboard, that dialog has focus. If I open the dialog via 
> > >> AT-SPI's AccessibleAction interfaces (e.g. 'click' and/or 'activate'), 
> > >> the dialog does not have focus. Now, it seems that this would be 
> > >> considered a bug, but even if it isn't, I can't seem to find an 
> > >> alternative way to ensure that the dialog is given focus.
> > >>
> > >> I did try using AccessibleComponent_grabFocus() on Accessibles which 
> > >> implement that interface, but ran into problems; for the vast majority 
> > >> of AccessibleComponents, the function returns FALSE, indicating that it 
> > >> was unsuccessful (which it was). Why would that function always fail?
> > >>
> > >> I did find that most (if not all) Accessibles with an 
> > >> AccessibleEditableText interface can successfully grabFocus, but even 
> > >> then, the window or dialog they're in must be focused; they will not 
> > >> grab focus from another window.
> > >>
> > >> So, my question is: How can an AT ensure that the same windows and UI 
> > >> controls that have focus after a given user action (i.e. with just the 
> > >> keyboard and/or mouse) is performed have focus when the same workflow is 
> > >> performed by the AT?
> > >>
> > >> Thanks,
> > >> Zack
> > >> _____________________________ http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
> > >>     
> > >
> > > _______________________________________________
> > > Gnome-accessibility-devel mailing list
> > > Gnome-accessibility-devel gnome org
> > > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
> > >   
> > 
> > -- 
> > Nagappan A <anagappan novell com>
> > Novell Software Development (I) Pvt. Ltd.
> > Linux Desktop Testing Project - http://ldtp.freedesktop.org
> > http://nagappanal.blogspot.com/
> > 
> > Novell, Inc.
> > SUSE® Linux Enterprise 10
> > Your Linux is ready™
> > http://www.novell.com/linux
> > 
> > _______________________________________________
> > Gnome-accessibility-devel mailing list
> > Gnome-accessibility-devel gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
> 
> 
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel