GNOME Bugzilla – Bug 301077
focus sometimes not reported after closing main menu
Last modified: 2018-04-15 00:23:20 UTC
Distribution/Version: JDS Rel3 B33 Using gnopernicus 0.10.5. - Start gnopernicus with speech enabled. - From the main menu, go to Preferences->Desktop Preferences->Display->Menus and Toolbars Notice that the Menu and Toolbar Preferences window appears. Focus is on the "Close" button and this is reported. - Press <Control> <Escape>. Notice that the main menu is opened and reported. - Press <Escape>. Notice that, although focus is now on the "Close" pushbutton in the Menu and Toolbar Preferences window, neither the change in focus to the window nor the pushbutton is reported by speech (or braille monitor). If the user presses <tab> then the current element is then reported.
Please see<i><a href="http://bugzilla.gnome.org/show_bug.cgi?id=169480#c64" title="NEEDINFO - Opening main menu with keynav not always getting reported">comment #64 of bug #169480</a></i> and apply similar logic here. Cache the last focus object, and when you get the expand/collapse event, if the source isn't the cached atk focus object, walk up through parents & grandparents comparing to the cached atk focus object.
Peter, your suggestion is not for this bug.
Seems that a window behave in 2 ways for apparantly same situation. When user moves from one window to another (ALT+TAB, mouse) then the window:activate event for window is received followed by a focus event for the focused object. In the case described in this bug, only the event for the window is received. So, for same action (activation of an window) 2 events flows are obtained, depending how the window gets activated.
That's right. Gnopernicus should be responding to the window:activate event here, and not depending on the focus: event.
>Gnopernicus should be responding to the window:activate event Are you sayng that in case of this event gnopernicus should present it and try to find the focus object and present it too? But why the focus event is not send by atk/gail? How the scenario described differs from tha ALT+TAB scenario?
It differs because of implementation details of the gtk+ toolkit. And in fact there isn't a true "focus" event because the object never lost focus, from the toolkit point of view. Gnopernicus should at least read the titlebar of the window when window:activate takes place.
The change (back) to the window is reported. Only the focus is not reported.
According to the bug report (initial comment), the change to the window is _not_ reported - or at least, the window title is not spoken. This is the bug.
This looks like it might be because this particular window is owned by metacity. Gnopernicus does speak other windows in this case.
Looking to the coming events, they are the same.
Created attachment 45778 [details] [review] proposed patch
For me with Cin 35, when I follow the steps John describes in the bug report, Gnopernicus does announce the focus on the Close button (and shows it in Braille). It really isn't clear to me that this behavior is wrong from a blind persons' point of view. John - are you (now) getting "close" spoken following your steps? If so, I think this bug report is really an RFE. I'm not ready to review/accept a patch until I'm certain this is in fact behavior desired by our customers.
It is odd, which situations the bug appears in, and which it doesn't appear in. I think we need to have a very carefully recorded data on the event flow in all of the possible situations - with various widgets in various dialog boxes having focus when the Launch menu appears and disappears.
I made some investigation Scenario 1: Gnopernicus' main window and Launch menu: Case1: AT:bfffe680p--key event:sym 65307 () mods 0 code 9 time 2203288 keystring "Escape" type 1 (press = 1, release = 2) AT:82b3888p----"object:state-changed:showing" for 82ba968p "" role "window" from "" with details 0 and 0 AT:82b3888p----"window:activate" for 82ba978p "Gnopernicus" role "frame" from "GAIL" with details 0 and 0 <SRSOUT markers="out-started:out-ended" id="82b05e8p"> <TEXT voice="system">switch to window</TEXT> <TEXT voice="name">Gnopernicus</TEXT></SRSOUT> AT:82b4cc0p----"object:state-changed:showing" for 80e9100p "" role "menu" from "GAIL" with details 0 and 0 AT:bfffe680p--key event:sym 65307 () mods 0 code 9 time 2203388 keystring "Escape" type 2 (press = 1, release = 2) Only the change of the window is reported and not the current focused object Case 2: AT:bfffe680p--key event:sym 65307 () mods 0 code 9 time 2214435 keystring "Escape" type 1 (press = 1, release = 2) AT:82b03d8p----"object:state-changed:showing" for 82b4138p "" role "window" from "" with details 0 and 0 AT:82b0378p----"object:state-changed:showing" for 80e9100p "" role "menu" from "GAIL" with details 0 and 0 AT:82b3cb8p----"window:activate" for 82ba978p "Gnopernicus" role "frame" from "GAIL" with details 0 and 0 AT:82b39d8p----"focus:" for 82b0658p "1 Startup Mode..." role "push button" from "GAIL" with details 0 and 0 <SRSOUT markers="out-started:out-ended" id="82b9af8p"> <TEXT voice="system">switch to window</TEXT> <TEXT voice="name">Gnopernicus</TEXT></SRSOUT> AT:bfffe680p--key event:sym 65307 () mods 0 code 9 time 2214568 keystring "Escape" type 2 (press = 1, release = 2) <SRSOUT markers="out-started:out-ended" id="82b4b58p"> <TEXT voice="name">1 Startup Mode 3 Dots </TEXT> <TEXT voice="role">Push button</TEXT> <TEXT voice="system">shortcut</TEXT> <TEXT voice="shortcut">Alt 1</TEXT> <TEXT voice="state">available</TEXT></SRSOUT> The change of the window and the current focused object are reported Differences: the focus event for the push button is missing in Case 1. Other info: Case 1 is rare, most of the times, case 2 is present.
Modifying summary to reflect the current situation in comment #14. Lowering severity.
From conversation with Remus on 13Feb06: the claim is that with the exact same user sequence: pressing Ctrl-ESC to bring up the launch menu, and then ESC to close it - sometimes Gnopernicus receives a focus event on the control in the topmost window that was what was focused when Ctrl-ESC brought up the launch menu; other times it doesn't. Remus says this must be a gail bug. Remus notes that a focus event comes from the launch menu coming up.
This is simply a race condition, and it's not at all clear to me that it can be avoided in gail. Probably gail is getting its gtk signals in different orders here.
Bill - so you are saying that the focus event does come; just after other things? Or is something (gail?) suppressing it because it comes out of order. Looking at Ada's event log in comment #14, it doesn't appear that the focus event ever appears.
Peter - you are right, the 'focus:' event seems to be suppressed in the first case, I was looking at "state-changed:showing" for the menu which appears in a different order in the two cases. I am suspecting gtk+ here, but probably gail needs to be looked at closely as well. Thanks.
Since the source of the bug is the absence of the focus event, I'm transferring bug to atk/gail.
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
If anybody has time, could you please check again whether this issue still happens in gtk+ 3.2 (or if 3.2 is impossible: in 3.0 or 2.24) and update this report by adding a comment and changing the "Version" field? Thanks a lot for your help.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new