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

[Nagappan <anagappan novell com>]

Hi Bill,

Test case is available here -
http://bugzilla.gnome.org/show_bug.cgi?id=347481

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
>> _______________________________________________
>> 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
>   

-- 
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