GNOME Bugzilla – Bug 691468
No accessible key events
Last modified: 2013-03-13 18:04:34 UTC
Created attachment 233145 [details] key event listener Steps to reproduce: 1. Launch gnome-control-center 2. Launch the attached event listener in a terminal 3. Arrow around in gnome-control-center, type in its search entry Expected results: Each key press and release would appear in the terminal Actual results: No output in the terminal when focus is in gnome-control-center I can reproduce this in both stable and master.
Is this specific to gnome-control-center ?
I see same behaviour in gnome 3.4 which will be shipped with next debian stable. Please have a look to this issue because a stable release should contain a working control-center.
(In reply to comment #1) > Is this specific to gnome-control-center ? afaik yes. I can reproduce this in gnome-control-center only. This bug has a bad effect to orca. I can't stop speech by hitting control. So it's really anoying to use gcs (currently).
(In reply to comment #2) > I see same behaviour in gnome 3.4 which will be shipped with next debian > stable. We're not going to fix GNOME 3.4 unless patches are forthcoming for that version. (In reply to comment #0) > Created an attachment (id=233145) [details] > key event listener > > Steps to reproduce: > > 1. Launch gnome-control-center > 2. Launch the attached event listener in a terminal > 3. Arrow around in gnome-control-center, type in its search entry > > Expected results: Each key press and release would appear in the terminal > Actual results: No output in the terminal when focus is in gnome-control-center > > I can reproduce this in both stable and master. I couldn't get gnome-control-center, or cheese, or nautilus to print anything, so I doubt this is something related to gnome-control-center specifically.
The python script only worked with older version of pyatspi apparently, so marking this as NEEDINFO until a reproducer is available.
I just tried the attached script using a live CD for F18. The script works for me as-is. I see keyevents in the terminal for nautilus (and gnome-shell and others). But I don't see them for gnome-control-center. So I think something has broken -- and done so quite recently -- in F18 regarding key-events across the board. :( If that is the case, creating a reproducer that works won't be possible as the environment itself is broken. But I'll update the live cd and see what happens.
Bastien, in a clean F18 fully updated, I still get key events. I went back to my desktop system where I wasn't getting them and noticed that I get them if NumLock is not enabled. Accessible key events disappear when NumLock is enabled. That's very very bad. But it hopefully means that you can now reproduce the bug in my opening report using F18 and the listener in the opening report. Just be sure NumLock is not locked.
(In reply to comment #5) > The python script only worked with older version of pyatspi apparently, so > marking this as NEEDINFO until a reproducer is available. FWIW, I was able to reproduce it on my jhbuild environment. The conclusion is that this is a clutter-gtk issue. I have key events for pure clutter applications and pure gtk applications, but not clutter-gtk applications. See bug 686622 comment 5 for more info.
Created attachment 237556 [details] Clutter setting file that disable a11y With this settings file clutter accessibility is not loaded. As explained here [1] you just need to place it at $XDG_CONFIG_HOME/clutter-1.0 directory (in my personal case /home/user/.config/clutter-1.0/settings.ini) With the accessibility of clutter don't activated I get the previous keyevent listener working on gnome-control-center. But I would like to do a full test with orca, and right now I don't have a working orca on my jhbuild environment. Could someone (probably joanie) test gnome-control-center using that clutter settings? If all the stuff keeps working I thing that (at least for gnome-control-center) a solution could be disable clutter accessibility support for clutter-gtk (as it is not required/used), doing a little change on clutter-gtk. [1] http://developer.gnome.org/clutter/unstable/running-clutter.html
That gives me key events both in the script in the opening report and in Orca.
(In reply to comment #10) > That gives me key events both in the script in the opening report and in Orca. Ok, thanks for the testing (as I assume that you also tested not new regressions). So next step would be create a patch that will avoid loading the clutter accessibility support for clutter-gtk. And as we concluded that this is a clutter-gtk bug, moving to the correct component.
Created attachment 237636 [details] [review] Set envvar CLUTTER_ENABLE_ACCESSIBILITY to false Tested with gnome-control-center and works. Next step is reviewing at the rest of the modules using clutter-gtk. Note that this patch depends on bug 694886
From https://mail.gnome.org/archives/desktop-devel-list/2013-February/msg00063.html, a initial list of modules could be: [mclasen@golem ~]$ rpm -q --whatrequires "libclutter-gtk-1.0.so.0()(64bit)" libchamplain-gtk-0.12.3-5.fc19.x86_64 cheese-libs-3.7.4-2.fc19.x86_64 totem-3.6.3-3.fc19.x86_64 cheese-3.7.4-2.fc19.x86_64 gnome-photos-3.7.3-4.fc19.x86_64 gnome-initial-setup-0.6-2.fc19.x86_64 eog-plugins-3.6.1-2.fc19.x86_64 gnome-games-gnibbles-3.6.1-2.fc19.x86_64 gnome-games-quadrapassel-3.6.1-2.fc19.x86_64 gnome-games-swell-foop-3.6.1-2.fc19.x86_64 gnome-games-lightsoff-3.6.1-2.fc19.x86_64 empathy-3.7.5-2.fc19.x86_64 gnome-color-manager-3.7.5-1.fc19.x86_64 gnome-boxes-3.7.5-1.fc19.x86_64 control-center-3.7.5.1-1.fc19.x86_64 sushi-3.7.5-1.fc19.x86_64 gnome-documents-3.7.5-1.fc19.x86_64 During the following days, I will take a look to those and other modules. As I said, the case of gnome-control-center is fixed with the patch at comment 11. And as mentioned on the thread and at bug 686622, boxes case is really particular, and probably too late in the cycle to solve their accessibility support.
Review of attachment 237636 [details] [review]: eeek, setting an envvar is not really nice. can't we have a clutter_disable_accessibility() function to be called before clutter_init() instead?
I can confirm that disabling a11y with clutter's settings.ini fromcomment 9 fixed my issue in gcs under debian wheezy. Thx a lot for your great and fast help in that important Area! I.ll now give feedback to debian community :-).
Halim, just to be clear: You know that disabling a11y with the settings.ini disables it across the board for clutter-based apps, right? For instance, it makes GNOME Shell no longer accessible. It looks like soon we'll have a proper fix which hopefully the Debian community will be able to backport.
This might be the reason why I did not see much difference after disabling clutter a11y. I don't use gnome shell. Maybe others will do so a fix should be really backported to get a11y working in next debian stable. Thx
(In reply to comment #14) > Review of attachment 237636 [details] [review]: > > eeek, setting an envvar is not really nice. Yeah I know but ... > can't we have a clutter_disable_accessibility() function to be called before > clutter_init() instead? ... as we were on the API/ABI freeze I didn't want to add new methods and just used what we already had available (well, in theory, as we know due bug 694886 that envvar was not being checked). Anyway, taking into account that you don't worry too much about that, I will add that new method and then we could send a break request.
clutter, like gtk, doesn't *really* subscribe to API freeze - given that it's too low on the stack, and used outside of gnome as well. also, I don't consider adding a function an API/ABI break - certainly not like changing a function this late in the development cycle. we just need to ensure that there are lock-step releases of clutter and clutter-gtk, with their minimum requirements changed.
Created attachment 237687 [details] [review] Add method clutter_disable_accessibility As suggested on comment 14
Created attachment 237688 [details] [review] Uses the method clutter_disable_accessibility instead of envvar This makes the dependency to bug 691468 obsolete. Anyway, I will not close that bug, as I think that the bug is still valid.
I tried the patches in my jhbuild environment: * gnome-control-center: fixed * empathy: fixed * totem: Didn't see anything broken * cheese: Didn't see anything broken * games: tend not to lend themselves to use by Orca users so I didn't test those. Having this committed would be nice. Thanks!
Forgot to mention: gnome-documents no longer uses clutter-gtk
*** Bug 681375 has been marked as a duplicate of this bug. ***
Review of attachment 237687 [details] [review]: ::: clutter/clutter-main.c @@ +511,3 @@ + * + * Disable loading the accessibility support. It has the same effect + * that setting the environment variable "the same effect as". @@ +513,3 @@ + * that setting the environment variable + * CLUTTER_DISABLE_ACCESSIBILITY. For the same reason, this method + * should be called before clutter_init. missing () to establish the link in the documentation. @@ +519,3 @@ +void +clutter_disable_accessibility (void) +{ should probably add a check to see if clutter has been initialized already, then warn and return if so. ::: clutter/clutter-main.h @@ +100,3 @@ /* Debug utility functions */ gboolean clutter_get_accessibility_enabled (void); +void clutter_disable_accessibility (void); missing CLUTTER_AVAILABLE_SINCE_1_14 annotation.
Review of attachment 237688 [details] [review]: looks good.
Created attachment 238718 [details] [review] Add method clutter_disable_accessibility
(In reply to comment #25) > > missing CLUTTER_AVAILABLE_SINCE_1_14 annotation. And about this ... I guess that clutter version requirement on clutter-gtk should be updated. Should I provide that patch? Which version ? 1.13.7 (current one at clutter-1-14 configure.ac)? 1.14?
I configure.ac, I would require the actual version that added the symbol (ie 1.13.7) - thats different from 'since' in the docs where I would always bump to 'next stable api version', ie 1.14.
what Matthias said: in the configure.ac of clutter-gtk you need to bump the required version of Clutter to the one that exposes the symbol - i.e. 1.13.7.
Created attachment 238793 [details] [review] Disable clutter accessibility support (In reply to comment #30) > what Matthias said: in the configure.ac of clutter-gtk you need to bump the > required version of Clutter to the one that exposes the symbol - i.e. 1.13.7. I assume this as a 'yes' to my question "Should I provide that patch?". So I just modified previous reviewed patch in order to bump the required version of Clutter.
(In reply to comment #27) > Created an attachment (id=238718) [details] [review] > Add method clutter_disable_accessibility I didn't say anything, but fwiw, this is the same patch that I uploaded on comment 20 but updated with the comments at comment 25.
Review of attachment 238793 [details] [review]: looks okay
Review of attachment 238718 [details] [review]: you can simply commit the patch with the change below, as far as I'm concerned. ::: clutter/clutter-main.c @@ +520,3 @@ +clutter_disable_accessibility (void) +{ + g_return_if_fail (!clutter_get_accessibility_enabled ()); I meant doing: if (clutter_is_initialized) { g_warning ("clutter_disable_accessibility() can only be called before " "initializing Clutter."); return; }
(In reply to comment #34) > Review of attachment 238718 [details] [review]: > > you can simply commit the patch with the change below, as far as I'm concerned. Patch committed with that change. Thanks for the review, and sorry for being a pest. I had the feeling that was an endless process. Closing the bug.
absolutely not: it's totally my fault, I haven't been keeping on top of this bug as I should have. thanks a lot!