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 671918 - gnome-shell is inaccessible unless started while an AT is listening
gnome-shell is inaccessible unless started while an AT is listening
Status: RESOLVED FIXED
Product: at-spi
Classification: Platform
Component: at-spi2-atk
unspecified
Other Linux
: Normal major
: ---
Assigned To: Mike Gorse
At-spi maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2012-03-12 16:29 UTC by Joanmarie Diggs (IRC: joanie)
Modified: 2012-03-14 11:34 UTC
See Also:
GNOME target: 3.4
GNOME version: 3.3/3.4


Attachments
Piñeiro's patch to the bridge to print out debug messages (613 bytes, text/plain)
2012-03-12 16:29 UTC, Joanmarie Diggs (IRC: joanie)
  Details
More deregister (1.08 KB, patch)
2012-03-13 17:55 UTC, Alejandro Piñeiro Iglesias (IRC: infapi00)
none Details | Review
orca debug file (72.77 KB, text/plain)
2012-03-13 18:04 UTC, Alejandro Piñeiro Iglesias (IRC: infapi00)
  Details
Patch. (929 bytes, patch)
2012-03-13 21:05 UTC, Mike Gorse
none Details | Review
Invalidate single_va_closure when adding an emission hook (911 bytes, patch)
2012-03-14 10:01 UTC, Matthias Clasen
committed Details | Review

Description Joanmarie Diggs (IRC: joanie) 2012-03-12 16:29:34 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....
Comment 1 Alejandro Piñeiro Iglesias (IRC: infapi00) 2012-03-12 16:38:57 UTC
(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.
Comment 2 Mike Gorse 2012-03-12 20:00:50 UTC
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.
Comment 3 Alejandro Piñeiro Iglesias (IRC: infapi00) 2012-03-13 17:55:49 UTC
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.
Comment 4 Alejandro Piñeiro Iglesias (IRC: infapi00) 2012-03-13 18:04:04 UTC
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)
Comment 5 Mike Gorse 2012-03-13 20:32:40 UTC
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.
Comment 6 Mike Gorse 2012-03-13 21:05:02 UTC
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.
Comment 7 Alexander Larsson 2012-03-14 09:58:01 UTC
Thats is right, not sure how i missed it, please commit.
Comment 8 Matthias Clasen 2012-03-14 10:01:16 UTC
The following fix has been pushed:
53b1afb Invalidate single_va_closure when adding an emission hook
Comment 9 Matthias Clasen 2012-03-14 10:01:19 UTC
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.
Comment 10 Alejandro Piñeiro Iglesias (IRC: infapi00) 2012-03-14 11:34:15 UTC
(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?)