GNOME Bugzilla – Bug 134003
cannot change layer whilst focusing icon
Last modified: 2004-12-22 21:47:04 UTC
using gnopernicus from 9th Feb 2004. -launch gnopernicus -launch nautilus -focus a file in 'icon view' -attempt to change layer, e.g. to layer 5, "np-0, np5" .gnopernicus does not switch layer, instead outputs the currently focused icon. Focusing the 'open with..' button in the left side-panel(whilst in information view) and retrying does change layer.
If I focus a file in 'icon view' in nautilus and the NumLock key is on, every time when I press a numpad key a focus event for the focused file will be emitted. So, to change the layer, e.g. to layer 5, I press 0 from numpad (and a focus event occurs) followed by 5 from numpad (and an other focus event occurs). I ran gnopernicus with GNOPERNICUS_LOG set to at-spi and the following output was emitted when 'bin' folder is focused (in nautilus, 'icon view') and I try to switch to layer 5: AT:80e2610p----"focus:" for 80e06c0p "bin" role "icon" from "GAIL" with details 0 and 0 AT:80e6c30p----"object:selection-changed" for 80e38c8p "Icon View" role "layered pane" from "GAIL" with details 0 and 0 AT:bfffdf10p--key event:sym 65363 (S) mods 10 code 102 time 1542551 keystring "Right" type 2 (press = 1, release = 2) <SRSOUT priority="0" preempt="true"><TEXT voice="name">bin Folder</TEXT><TEXT voice="role">Icon</TEXT></SRSOUT> AT:bfffe6b0p--key event:sym 65456 (°) mods 10 code 90 time 1542913 keystring "0" type 1 (press = 1, release = 2) AT:bfffe6b0p--key event:sym 65456 (°) mods 10 code 90 time 1543002 keystring "0" type 2 (press = 1, release = 2) AT:80e5f90p----"focus:" for 80e06c0p "bin" role "icon" from "GAIL" with details 0 and 0 <SRSOUT priority="0" preempt="true"><TEXT voice="name">bin Folder</TEXT><TEXT voice="role">Icon</TEXT></SRSOUT> AT:bfffe6b0p--key event:sym 65461 (µ) mods 10 code 84 time 1543252 keystring "5" type 1 (press = 1, release = 2) <SRSOUT priority="0" preempt="true"><TEXT voice="system">layer 5</TEXT></SRSOUT> AT:bfffe6b0p--key event:sym 65461 (µ) mods 10 code 84 time 1543311 keystring "5" type 2 (press = 1, release = 2) AT:80e1418p----"focus:" for 80e06c0p "bin" role "icon" from "GAIL" with details 0 and 0 <SRSOUT priority="0" preempt="true"><TEXT voice="name">bin Folder</TEXT><TEXT voice="role">Icon</TEXT></SRSOUT>
I will have a look at this.
I am not seeing this behavior on Solaris; see below. AT:137988p----"focus:" for 1280f0p "4256368" role "icon" from "GAIL" with details 0 and 0 AT:137730p----"object:selection-changed" for 128d00p "Icon View" role "layered pane" from "GAIL" with details 0 and 0 AT:ffbfd940p--key event:sym 65363 (S) mods 20 code 83 time -828788972 keystring "Right" type 2 (press = 1, release = 2) <SRSOUT priority="0" preempt="true"><TEXT voice="name">4256368 Folder</TEXT><TEXT voice="role">Icon</TEXT></SRSOUT> AT:ffbfd940p--key event:sym 65438 () mods 20 code 102 time -828781076keystring "" type 1 (press = 1, release = 2) AT:ffbfd940p--key event:sym 65438 () mods 20 code 102 time -828780996keystring "" type 2 (press = 1, release = 2) AT:ffbfd940p--key event:sym 65500 (\334) mods 20 code 97 time -828780324 keystring "" type 1 (press = 1, release = 2) <SRSOUT priority="0" preempt="true"><TEXT voice="system">layer 5</TEXT></SRSOUT> AT:ffbfd940p--key event:sym 65500 (\334) mods 20 code 97 time -828780260 keystring "" type 2 (press = 1, release = 2)
We may need some help from Bill on this.
For me seems that this bug is a duplicate of bug 108664.
I do not think this is a dup of 108664.
Created attachment 25046 [details] a "human readable" output from gnopernicus
I still believe that this is a duplicate of 108664. The patch above shows that unwanted events are received by gnopernicus.
The question is, why does this happen only while icons are focussed? That doesn't make sense, because it's not clear how the icon being focussed affects the rest of the event history (as received by at-spi internals).
I am not seeing the behavior reported by Remus on my Solaris box. Remus, Does increasing the value of 200 in line 951 of at-spi/regostryd/registry.c change the behavior?
I increased the value to 900 then to 2000. By doing that, no events for window are received by gnopernicus, but a new focus event for current object is again received.
Created attachment 26402 [details] a modified file from gnopernicus This file (from gnopernicus/kbd_mouse/libke) contains only the interested part in this bug. The time to process an event is very short, the tester will show the event and will return.
Created attachment 26403 [details] a new tester This is same as previous, except that it registers only one key combination.
The file should be copied in gnopernicus/kbd_mouse/libke, then gnopernicus should be recompiled. To see the unwanted focus event the following commnad must be run before: export GNOPERNICUS_LOG=at-spi
Remus, Please change line 28 of at-spi/registyy/registy.c to #define SPI_QUEUE_DEBUG and rebuild. Then run at-spi-registryd in an xterm using the command below and reproduce the problem. I am hoping that the output from at-spi-registyd will allow me to understand why the focus events are happening. kill <pid>; `which at-spi-registryd` --oaf-activate-iid=OAFIID:Accessibility_Registry:1.0 --oaf-ior-fd=33
Remus: do you see the same behavior with a standalone test program (for instance, a modified version of key-listener-test) which listens for the same key combination as your most recent patch aboves? That would greatly simplify debugging if we need to get nautilus involved too.
Created attachment 26461 [details] [review] a standalone tester The source file is a modified file from at-spi/test directory. It register a listener for one key from numpad (key "0") and another listener for focus and all window events.
Created attachment 26463 [details] output required by Padraig
thanks Remus for the standalone tester and the outpu, this should help a lot.
I an running the test program in one terminal and at-spi-registryd in another terminal I have nautilus running with an icon in the icon view selected. I assume I now press 0 on the numeric keypad with NumLock on. What output do you see from the test program?
*** Bug 138391 has been marked as a duplicate of this bug. ***
*** Bug 139390 has been marked as a duplicate of this bug. ***
Created attachment 26864 [details] [review] output created by tester proposed at comment #17
I am reproducing this on Solaris using page tab (Untitled 1) in gedit. It looks like the problem occurs only when an object which does not correspond to a GtkWidget has focus, e.g. Notebook page icon or icon. It does not seem to happen when an object corresponding to a widget has focus, e.g. down arrow toggle button in gedit. I do not see any difference in output from at-spi-registryd when focus is on page tab and toggle button. I need to investigate some more.
The focus event is discarded when the focus object corresponds to a GtkWidget and not otherwise. I need to see why. I am transferring to at-spi as that is the correct place for the bug now.
I think I understand what is happening. In registry.c the focus_object is set when a state-change:focused event is discarded after a window:deactivate event is received because a window:activate event has been received for the same window within the timeout period. The focus object is used to suppress a focus event for that object. It is released when a window:deactivate event is received. When we have the problem the object in the state-change:focused event is the Notebook not the NotebookPage which we report as having focus. Also the Notebook is reported as having state ATK_STATE_FOCUS set when we report the NotebookPage as having focus. I assume that both of these are incorrect.
Created attachment 26899 [details] [review] Proposed patch Remus, Can you check that the proposed patch works for you.
Padraig: if the patch is applied, does the focus-event source (in this case, the GtkNotebook page) have state FOCUSSED? I think we're agreed that focus: event sources always should; otherwise the patch seems right to me.
The GtkNotenbook page does have state focused; that was fixed in bug #127400. It is nothing to do with this patch.
Thanks Padraig for confirming, I had forgotten the patch for 127400. I take it that this patch fixes the reproducible test case we were looking at, which is great news; it's nice to have an explanation of why the focus: rejection logic was failing.
The bug is still present. When I tried to change the layer, everything was OK, but When I tried another command (layer 0 key 9) gnopernicus worked in same way (unwnated event were received). Also the bug seems to be present when a key from numpad is pressed and held for a while. Also I observed the bug in same conditions when I run gnopernicus and the tester (#17) in same time. I checked with "Enable repeat keys" on and off, but still same results.
<SRSOUT priority="0" preempt="true"><TEXT voice="name">136625_files Folder</TEXT><TEXT voice="role">Icon</TEXT></SRSOUT> <SRSOUT priority="0" preempt="true"><TEXT voice="system">layer 9</TEXT></SRSOUT> <SRSOUT priority="0" preempt="true"><TEXT voice="system">layer 5</TEXT></SRSOUT> When I tried gnopernicus from CVS HEAD with an icon focused in nautilus I got the output above which looks correct. How can I reproduce the problem?
Remus: do your event logs look the same in the new test case? And can it be reproduced with the standalone test program? If not, then either this bug is fixed and a new bug needs to be opened, or the test program is invalid/incomplete.
I have committed this patch to CVS HEAD and am marking this bug as fixed. Please open a new bug if there are issues still unresolved.
*** Bug 140942 has been marked as a duplicate of this bug. ***