After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 568696 - locus of focus changes when updating list of files in nautilus
locus of focus changes when updating list of files in nautilus
Status: RESOLVED FIXED
Product: orca
Classification: Applications
Component: general
2.25.x
Other Linux
: Normal normal
: 2.28.0
Assigned To: Willie Walker
Orca Maintainers
: 588581 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-01-22 14:23 UTC by Javier
Modified: 2009-11-09 21:35 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24


Attachments
Potential patch (1.06 KB, patch)
2009-05-25 11:41 UTC, Willie Walker
committed Details | Review
Patch to put decision logic in the script (10.31 KB, patch)
2009-07-16 20:04 UTC, Willie Walker
committed Details | Review

Description Javier 2009-01-22 14:23:10 UTC
While you are working with any application and some item is deleted or added to some nautilus folder opened,
Orca's locus of focus changes to the nautilus application, however the focus is in your application.

1. Open terminal
2. cd to the Desktop folder
3. Create a new file or delete one from the desktop folder

Orca should not change locus of focus while you are in another application.
Comment 1 Willie Walker 2009-02-09 16:44:39 UTC
I was able to reproduce this using these exact steps:

1) Open a nautilus window and point it to the Desktop folder
2) In a gnome-terminal window, type these commands:

cd ~/Desktop
touch foo
touch bar
rm bar

3) Orca presents the foo icon in nautilus instead of staying in gnome-terminal

What I'm seeing is that the "rm bar" ends up causing a focus event to occur in nautilus, giving focus to "foo". So, Orca ends up thinking focus has moved to the nautilus window.

I think the issue boils down to some logic in focus_tracking_presenter.py:_processObjectEvent around line 659:

                    # Or, we might just be getting a focus event.  In this
                    # case, assume the window has focus and we missed an
                    # event for it somehow.
                    #

We might want to add an additional check to see if the ACTIVE state is set on the window associated with the event object.  I'm not sure, though, since the ordering window activation and object focus events tend to be somewhat under-specified.  Need to think about this one for a bit.
Comment 2 Willie Walker 2009-05-25 11:41:27 UTC
Created attachment 135312 [details] [review]
Potential patch

This patch adds one more check before setting the active script -- it makes sure the new application (if it exists) has a direct child (i.e., one of its windows) with an ACTIVE state.  This *seems* reasonable to me, but I'd like it to soak a while before committing it.

Javier - please test with this for a while if you are able to do so.
Comment 3 Mesar Hameed 2009-05-27 21:44:37 UTC
this patch works well for me.
Comment 4 Javier 2009-05-28 09:19:40 UTC
Sorry for the late response. I have tested it and works great. I have been touching some files in the desktop and saving documents into it from Gedit and the bug seems fixed. 
Now I have to check it with an Nautilus window opened?
Comment 5 Javier 2009-05-28 09:40:48 UTC
If we open desktop folder in a Nautilus window and touch some files and remove it from terminal, the patch works as expected.
However, when  we work from Nautilus in the desktop folder and create new files or remove it, Orca says the name of other elements and not selected, from the desktop one and new desktop nautilus window. This happend I suposse cause now the script is active?
Anyway, now the active window doesn't loose focus, that was the main problem.
Comment 6 Willie Walker 2009-07-14 21:48:30 UTC
*** Bug 588581 has been marked as a duplicate of this bug. ***
Comment 7 Willie Walker 2009-07-14 21:49:39 UTC
The patch for this bug causes top panel items to no longer be spoken. :-(  Reverting.
Comment 8 Willie Walker 2009-07-16 20:04:39 UTC
Created attachment 138559 [details] [review]
Patch to put decision logic in the script

This patch puts the "should the event really cause me to become active?" logic in the script.  Seems to work nicely.  Please give it a try.