GNOME Bugzilla – Bug 529847
If I first start an administration application, after write my password and click ok button, Orca lost focus.
Last modified: 2008-08-19 20:28:11 UTC
Please describe the problem: I using Ubuntu Hardy and Orca 2.22.1 release. Tryed and tested the administration application use workaround with publicated the Orca mailing list some day ago (putted the .orbitrc file with /root directory and modifyed /etc/sudoers file with Defaults env_keep+="GTK_MODULES") and see interesting problem. I logged with normal user name privileges. When I launched first time an administration application for example with Login Manager, the password request dialog is displayed. If I wroted my password and clicked the Ok button, Orca losed speech, and for example the Login manager is unusable with Orca. If I closed the Login Manager and started again, Orca speech correctly with Login Manager (the password request dialog is not displayed). I maked a debug.out file and looked in what happened after when i wroted my password and clicked the Ok button? I surprised, I seed lot of traceback error messages with debug.out file after clicked the ok button, not quoted every error messages, few messages quoted: "Traceback (most recent call last): File "/var/lib/python-support/python2.5/orca/focus_tracking_presenter.py", line 533, in _processObjectEvent state = event.source.getState() File "/usr/lib/python2.5/site-packages/pyatspi/accessible.py", line 237, in _inner raise LookupError(e) LookupError LookupError above while processing event: object:state-changed:focused Traceback (most recent call last): File "/var/lib/python-support/python2.5/orca/focus_tracking_presenter.py", line 533, in _processObjectEvent state = event.source.getState() File "/usr/lib/python2.5/site-packages/pyatspi/accessible.py", line 237, in _inner raise LookupError(e) LookupError LookupError above while processing event: object:property-change:accessible-name Traceback (most recent call last): File "/var/lib/python-support/python2.5/orca/focus_tracking_presenter.py", line 533, in _processObjectEvent state = event.source.getState() File "/usr/lib/python2.5/site-packages/pyatspi/accessible.py", line 237, in _inner raise LookupError(e) LookupError LookupError above while processing event: object:property-change:accessible-name Traceback (most recent call last): File "/var/lib/python-support/python2.5/orca/focus_tracking_presenter.py", line 533, in _processObjectEvent state = event.source.getState() File "/usr/lib/python2.5/site-packages/pyatspi/accessible.py", line 237, in _inner raise LookupError(e) LookupError LookupError above while processing event: object:property-change:accessible-name" I tryed tested this problem with Orca developing version (svn trunk, 2.23.1), but the problem is present. Sending in attachment the debug.out file with generated with Orca 2.23.1 version. Steps to reproduce: 1. 2. 3. 1. Logging with normal user with gnome. 2. Pressing alt+f1 key (open the applications menu). 3. Choosing system/administration/login manager menu item and press enter. 4. Writing my normal password (gksu confirm dialog). 5. Wait. 6. Wait. 7. Wait, not happen nothing, Orca not speech. 8. Closing Login manager. 9. Repeating 2. and 3. step, and the login manager possible using with Orca. Actual results: Expected results: Does this happen every time? Other information:
Created attachment 109887 [details] This is a debug.out file with represent the problem.
Atilla: Have you been able to resolve this and have you looked at http://live.gnome.org/Orca/SysAdmin? Will
Will, I looked the Orca sysadmin section with http://live.gnome.org/Orca homepage, but every settings is correct and not resolve my problem. The /etc/sudoers file present this line: Defaults env_keep+="GTK_MODULES" The /root/.orbitrc file is present. Attila
*** Bug 516370 has been marked as a duplicate of this bug. ***
Hi Attila: Please also check to make sure the "Disable gksu keyboard grab" checkbox in the "General" tab in the Orca preferences dialog is checked. If this is the case, please attach your /root/.orbitrc and /etc/sudoers files to this bug so we can take a look at them. Thanks! Will
Created attachment 111657 [details] This is my /root/.orbitrc file. This is my /root/.orbitrc file.
Created attachment 111658 [details] This is my /etc/sudoers file. This is my /etc/sudoers file.
Mike can you try to reproduce this?
Saddly I'm unable to reproduce this problem.
Mike, you tryed launch for example with login manager with system/administration menu and speech correct after the password request window? You wroted do not reproduce the problem. My sudoers file wrong? What means the lot of traceback error messages?
Hi Attila: Please also check to make sure the "Disable gksu keyboard grab" checkbox in the "General" tab in the Orca preferences dialog is checked. Thanks! Will
Will, the disable gksu keyboard grab checkbox is checked my Orca preferences in general tab, but not solve my problem. Attila
We're having a really hard time duplicating this one, so we went back and re-read the debug log in more detail. There was an issue in the debug log that we also recently noticed when looking at bug #540124. Can you please try applying the patch attached to that bug and see if it helps with the problem you're experiencing with this bug?
Sorry Will, tryed your attached patch with bug #540124, but not solved my problem. In long period time, the possible fix is policy kit integration with all administration applications for example with Ubuntu (network manager, service manager). This two or four applications integrated the polkyt feature, and Orca speak correctly after I click the unlock button and wroted my password. This applications not use the gksu feature but usable fine with Orca, because only need tasks running with root privileges. But it is not Orca developers problem, because this question is very complex, but critical with accessibility and system administration. What your openion? Attila
(In reply to comment #14) > Sorry Will, tryed your attached patch with bug #540124, but not solved my > problem. In long period time, the possible fix is policy kit integration with > all administration applications for example with Ubuntu (network manager, > service manager). This two or four applications integrated the polkyt feature, > and Orca speak correctly after I click the unlock button and wroted my > password. This applications not use the gksu feature but usable fine with Orca, > because only need tasks running with root privileges. > But it is not Orca developers problem, because this question is very complex, > but critical with accessibility and system administration. > > What your openion? We're having a heck of a time trying to reproduce this. So, if there is a migration path away from the problem (gksu to PolicyKit?) I might be tempted to regretfully close this bug. Before doing so, however, can you try to confirm that a simple workaround might work? With your /root/.orbitrc and /etc/sudoers file in place as you've posted them here, try running the command using sudo from the command line. I'd try, but I seem to have corrupted my /etc/sudoers file and I need to recover. :-(
Closing because we cannot reproduce. In addition, policy kit should hopefully be the ultimate solution.