GNOME Bugzilla – Bug 88033
"Menus" button not being activated
Last modified: 2004-12-22 21:47:04 UTC
The "Menus" button is not being activated when a Gnome 2 application is started and focused. I tested with: gedit gnome-calculator To recreate do the following: 1. Start gok 2. Start app in a separate shell with GTK_MODULES='gail:atk-bridge' 3. Give app focus 4. Gok enables the "UI grabber" button but not the "Menus" button 5. Choose "UI grabber" and then "back" and now "Menus" is active
This seems to now be fixed.
this is still a problem in some cases, particularly with the terminal; for instance when switching workspaces. GOK doesn't always pick up the menu as it should.
I see that GOK doesn't reliably pick up the current application's settings; seems that GOK is failing to recognize when a context switch occurs. * For instance, it tends to show the most recently displayed at-spi-aware menu when you cycle to a non-at-spi-aware app (like emacs, etc.). * Further, sometimes it shows the menu from the wrong app, for instance if you focus 'gnome-terminal' it may still show you the menus from gedit. That's doubly bad.
This is a known issue. Are there plans to proxy non-atspi-aware (naa) apps. with some simple accessbility (e.g. focus events), perhaps through the window manager? If not, what is the event to listen for when a user switchs from a compliant to naa app/window (e.g. gedit to emacs)?
no, there are no plans for such support. However it should not be needed; instead, on listens for state changes on the 'accessible' applications when they get focus. So, if an AT client is listening for state change events on the toplevel (application) accessible objects, it can detect when various apps gail or lose the foreground. I would suggest ignoring state-change events from objects other than the one(s) immediately being used by GOK keyboards. That is, if you listen for all state-changed events you will get a lot of them in some situations, I would discard those that are not immediately of interest. There are several strategies: GOK can listen for focus: events and work its way up to the toplevel application, to figure out what's focussed; this works for at-spi-aware apps but of course not 100% reliably since in some cases focus events may not be emitted when an at-spi-aware application is brought to the front. Probably better would be to enumerate the application objects and toplevel windows (via the desktop object), and find the one (if any) which is currently focussed (via the atk_object_get_state API). I believe that the 'focussed' state is the one to look for: Padraig? Once this is done, listening for object:state-changed events will let know know if a toplevel loses focus - test the state-changed events against the last-known 'active' toplevel, and if it's a match, check to see if the event indicates that the toplevel has lost focus.
David, should I take this bug?
Changing priority to map onto "stopper", "maybe stopper", etc.
Created attachment 15031 [details] [review] unfinished patch to address this bug
The patch above changes gok's notification of window change from listening to "focus" events to "window:activate" and "window:deactivate" events. It also fixes some problems with the processing of the gok internal event queue. It seems to address the problems outlined in this bug but we are seeing some segmentation faults. The segmentation faults may be unrealted to this work however.
Thanks Simon, I'll proceed.
Simon, since we agree the modifications in our earlier patch are high risk for csun, I will attach another patch that reverts to the focus events for observing new 'windows' (commenting out the window:activate code), but kept the window:deactivate fix for when changing focus from an at-spi compliant app to a non-compliant one. Also this modified patch cleans up the ref count problem we introduced. This patch stress tested fairly well, but I was still able to get badness. Sorry for lack of detail - rushed. I might work on this on the weekend but will check back here first.
Created attachment 15038 [details] still unfinished (see previous comment)
oh dear. I will look at this as time permits, but I won't have much further web access.
guys: if you can send me info on these crashers (i.e. when the occur) ASAP then I can at least test for them with a separate patch. thanks
Bill, it is hard to recreate the crashes consistently. In general, it requires extreme stress testing to recreate.
David - do you have any evidence that this was triggered by the new code? (just wondering).
No. I will put the cvs version of gok through similar stress tests once I my system is back up and running.
Hi David. Sorry to hear about the system problems. Tell you what - *if* time permits I will have an independent go at this bug, my initial guess was that it would only take a couple of hours. It's possible that I'll either cop onto the problem or just by accident avoid it, if indeed it was introduced by the above patch.
Righto, just be sure to test test ;-)
Bill, I would like to apply the latest patch so that cvs us up to date. That is unless you have come up with a better one ;-)
david: does your latest patch differ from the one you posted on march 14?
Nope, it doesn't differ at all.
David/Simon: go ahead and apply the patch, but: * you might want to look at the ref counting, it looks as though you are unreffing twice on receipt of a 'defunct' event. perhaps this was causing some of the problems you reported. * it's hard to read with lots of stuff commented out in the focus-handler, perhaps we can remove the old code instead? I guess it's OK temporarily, since emacs will color-code this for me. thanks!
The patch has been applied.
The patch fixes the original behavior problem reported in the bug. However it fails to de-activate the menus/toolbars/uigrab buttons when the context switches from an 'accessible' window to one that does not implement at-spi. This is still a problem. It appears that window:deactivate events are being ignored in these cases.
Correction: testing with GOK HEAD and GNOME-2.3 HEAD, GOK seems to be receiving the window:deactivate events and responding correctly. However GOK does seg fault on context switch sometimes, which I am logging as a separate bug.
No, the behavior is not consistently correct. Often the wrong window's UI information is displayed, still.
David: re-examining the gok-spy code I see that you had commented out the activate/deactivate processing for CSUN. I un-commented this code and am seeing much better behavior. Undoubtedly we need to revisit the event behavior a bit more, but in the meantime I'd like to apply the patch I am about to attach, which seems to clear a number of existing GOK bugs of high priority that deal with GOK's reaction to window-switching events (or lack thereof). The patch is mostly just something to un-comment code you already wrote :-) Note that the use of a global for the currently active toplevel is problematic, as you apparently know already since I see comments regarding "activate" on a new window preceding "deactivate" on an old one. This indeed can happen and there's no way to prevent it; I think the best answer may be to either separate the concepts of "current toplevel" from "most recent toplevel" (since current is sometimes NULL when most recent is non-null) or to introduce a list of collection of known objects which GOK can use to lookup+unref on receipt of certain events such as DEFUNCT and DEACTIVATE. OK, so, OK to commit the attached patch? - Bill
Created attachment 16569 [details] [review] patch to reinstate some window-listening code.
Bill, I'm not sure this patch is against head is it? I recall uncommenting the defunct stuff already.
it's against HEAD all right. Sounds like I should apply it after confirming that... if your intention was to already have done it!
maybe you're right David, my cvs diff -u doesn't seem to turn this up anymore. Either I inadvertantly committed yesterday, or I had a sticky tag that I hadn't noticed.
Bill, I took a quick look and the last code commits where done on the 15th (by me). It looks like your last commit was on the 9th. Probably a sneaky sticky tag - that is unfortunate, I hope you didn't waste too much time on that. Shall we downgrade this bug?
Hi David; I am waiting to downgrade because I am seeing problems with GOK when using keynav on my machine. It seems possibly to be an at-spi problem but it may have to do with the order of activate/deactivate events, so I want to explore further before closing this bug. I am however optimistic that it's basically fixed (though the event handling code in GOK needs, I think, to be revised not to use the globals due to refcount issues on the static "current topmost").
Though I still think a bit of refactoring is in order, and think we should make GOK only use the "focus:" codepath (walking up the tree) on startup and not afterwards, I believe this bug is basically fixed as far as GOK is concerned. Unfortunately I have confirmed that GOK is getting bad or at least very inconvenient input from AT-SPI when keynav is used. However I think the correct place for that fix, if it's at all possible, is in AT-SPI and not GOK. Therefore I am, with some joy, closing this bug.