GNOME Bugzilla – Bug 671918
gnome-shell is inaccessible unless started while an AT is listening
Last modified: 2012-03-14 11:34:15 UTC
Created attachment 209508 [details] Piñeiro's patch to the bridge to print out debug messages Steps to reproduce: 1. Launch gnome-shell 2. Launch Orca 3. Attempt to interact with gnome-shell Expected results: Orca would present gnome-shell Actual results: Orca presents nothing in gnome-shell 4. Press Alt+F2, type r, press Return (to restart gnome-shell) 5. Attempt to interact with gnome-shell Expected and actual results: Orca presents gnome-shell Notes: Piñeiro helped look into this. 1. From a patch to Clutter, we verified that in both step 3 (Orca cannot present gnome-shell) and step 5 (Orca can present gnome-shell), Clutter/Cally is emitting signals. Orca simply is not getting them. 2. From a patch to at-spi2-atk, we verified that at step 3, we are not seeing these signals. But at step 5 we are seeing them. I have been using Fedora rawhide for a while now. This problem has only recently cropped up. I went back to earlier versions of AT-SPI2 and am still seeing the problem. So perhaps something changed in some other component that triggered this. Piñeiro's thoughts on this matter: <API> well, on the announcement <API> https://mail.gnome.org/archives/gtk-devel-list/2012-March/msg00004.html <API> alex larsson said: <API> "although it you're using an <API> non-standard signal marshaller for a heavily used signal you might want <API> to look at setting a custom va_marshaller." <API> so one question would be check if at-spi2 is using some kind of non-standard signal marshaler Lastly: I think this should be a gnome 3.4 blocker. Users having to restart gnome-shell in order to use it is really bad....
(In reply to comment #0) > Steps to reproduce: > > 1. Launch gnome-shell > 2. Launch Orca > 3. Attempt to interact with gnome-shell > > Expected results: Orca would present gnome-shell > Actual results: Orca presents nothing in gnome-shell > > 4. Press Alt+F2, type r, press Return (to restart gnome-shell) > 5. Attempt to interact with gnome-shell > > Expected and actual results: Orca presents gnome-shell > Adding more steps: Orca is presenting gnome-shell stuff properly. 6. Close Orca 7. Launch Orca again. 8. Attempt to interact with gnome-shell Expected results: Orca would present gnome-shell Actual results: Orca presents nothing in gnome-shell In order to solve this you need to go to step 4 again. > Lastly: I think this should be a gnome 3.4 blocker. Users having to restart > gnome-shell in order to use it is really bad.... From last release team meeting, in general using GNOME 3.4 target is basically a "would like to have flag". So I agree that this is something that we would like to solve so setting the target.
Commenting lines 150-151 of bridge.c seems to help. The bridge is doing the following: - registering event listeners - calling at-spi2-registryd to ask which event listeners have been registered - Seeing none, deregisters the event listeners. (We need to have them initially registered since at first we don't know whether or not anything is listening, and we do not block while waiting for an answer from at-spi2-registryd). - When Orca is run, re-register the event listeners It seems that registering the event listeners, deregistering them, and then re-registering them is not working correctly with gnome-shell.
Created attachment 209631 [details] [review] More deregister (In reply to comment #2) > Commenting lines 150-151 of bridge.c seems to help. I also needed to commenting lines 1052-1053, as you can see in the patch. Doing that, if I get Orca working properly with gnome-shell, and then I close and reload Orca, things keep working. Anyway, I still have some problems the first time that I open Orca. Anyway probably related with my jhbuild environment. So, my steps: 0. On classic gnome 1. a11y disabled ('org.gnome.desktop.interface' 'toolkit-accessibility to false) 2. Run at-spi-bus-launcher from my jhbuild environment (so master) 3. I make a gnome-shell --replace 4. I use the accessibility menu icon on the panel to open Universal Access Settings 5. Enable orca 6. Alt+Tab Alt+Tab switcher is open. Orca doesn't expose the current app, but it exposes "window". Looking at debug.out from orca, that window cames from gnome-shell. So gnome-shell is properly registered. 7. Reload gnome shell (alt+f2, r) 8. Alt+tab Now Orca works fine 9. Close and re-launch Orca 10. Alt+tab Orca is still working fine > The bridge is doing the > following: > > - registering event listeners > > - calling at-spi2-registryd to ask which event listeners have been registered > > - Seeing none, deregisters the event listeners. (We need to have them > initially registered since at first we don't know whether or not anything > is listening, and we do not block while waiting for an answer from > at-spi2-registryd). > > - When Orca is run, re-register the event listeners Taking into account steps 0-6, it seems that there are problems with the register if gnome-shell is already running before open Orca. > It seems that registering the event listeners, deregistering them, and then > re-registering them is not working correctly with gnome-shell. Take into account that gnome-shell is not exactly doing what gtk does. It loads by hand the bridge. My first action will check in which of the previous steps is loaded.
Created attachment 209632 [details] orca debug file Orca debug, doing the interaction as explained on comment 3 steps 5 and 6. Note that then Alt+Tab is pressed, "window" is exposed, as an event from GNOME Shell, but not the selected item. In the same way, it exposes out "Tab", but not the selection change. And those key events are coming from the ATK implementation at clutter. So clutter ATK implementation is there, but it seems that some events are not properly registered. Note that the missed events are state-change events. Since this commit: http://git.gnome.org/browse/clutter/commit/?id=cc126f55eb948a528211bc1649cd20bc7a7c0ed7 Clutter ATK implementation is not emitting "focus-change" anymore. Just state-change, as we agreed on bug 649575 comment 1 (real deprecation still pending)
This seems to be a regression introduced by the commit for bug 661140. There is a separate code path used if "there is only one closure handling a signal emission it doesn't have a bunch of complicated features enabled" (ie, if the signal node's single_va_closure is non-NULL and single_va_closure_is_valid is TRUE). Single_va_closure_is_valid is set to FALSE on various calls but not when an emission hook is added, as I think it should be. Need to write a test and then have Alex review the patch.
Created attachment 209652 [details] [review] Patch. Alexander, could you look at this patch, and would you like a test somewhere? If so, is there a place where you'd suggest adding it? Also, it wouldn't hurt if someone wanted to try applying it to glib and test that it fixes the issues with Orca/AT-SPI, although it seems to solve things for me.
Thats is right, not sure how i missed it, please commit.
The following fix has been pushed: 53b1afb Invalidate single_va_closure when adding an emission hook
Created attachment 209685 [details] [review] Invalidate single_va_closure when adding an emission hook If the optimization is used for only having one closure handling a signal emission, then hooks will not be run, so it should be disabled when an emission hook is added.
(In reply to comment #5) > This seems to be a regression introduced by the commit for bug 661140. > There is a separate code path used if "there is only one closure handling > a signal emission it doesn't have a bunch of complicated features enabled" > (ie, if the signal node's single_va_closure is non-NULL and > single_va_closure_is_valid is TRUE). Single_va_closure_is_valid is set to > FALSE on various calls but not when an emission hook is added, as I think > it should be. Need to write a test and then have Alex review the patch. Just to mention that I have tested with last glib and things are working now. Thanks (Btw, although not really relevant right now, as the bug is solved, shouldn't we move this bug to glib product?)