GNOME Bugzilla – Bug 554057
Calling gtk_menu_shell_select_item() on GtkMenuBar can break grabs (and create big accessibility issues)
Last modified: 2017-03-23 08:52:26 UTC
Steps to reproduce: 1. Login to ubuntu desktop. 2. Press <Alt><Ctrl><Tab> to move focus onto top gnome panel. 3. Press <Arrow> to select menu Applications-> Accessories->Text Editor, then press <Enter>. Expected result: After step3, the gedit can be invoked and the focus on the panel menu should be released. Actual result: The focus on panel menu is not released, it locks the focus, that makes user can not input anything in newly invoked gedit with keyboard only. Additional info: The focus is locked on the top gnome panel, user could only navigate focus within this panel. This bug is also visible on opensolaris.
I'm seeing this too with the gnome panel in GNOME 3. Until you figure out that you must re-click the panel toplevel menu items a couple of times to release the "stuck" focus, you cannot use the keyboard in any other application and you cannot even move windows (somehow, it blocks the mouse, not just the keyboard).
I'm also seeing this in 2.91.x. Given that Accessibility support in GNOME 3 proper is still a tad rough around the edges, some users will, unfortunately, have to rely upon fallback mode. If those users cannot use a mouse to get unstuck, the app that was launched via the panel menus cannot be navigated. :-(
I'm trying to reproduce but... How do you open the applications menu with the keyboard once you've focused it with ctrl+alt+tab and various tab? Or do you just do alt+f1?
Try this (or the equivalent): 1. Alt+F1 (applications menu) 2. Right Arrow (places menu) 3. Down Arrow (home menu item) 4. Return Nautilus appears. And I'd think focus would be in the Nautilus window somewhere. 5. Down Arrow (places menu reopens) I can repro this in 2.91.93 and 2.91.94
I've also been able to reproduce the bug with Joanie's details. I'm in 2.91.93, and I can get the right focus back to Nautilus by opening/closing the calendar and pressing Alt+Tab. Regards!
I'd think it's a bug in GTK+: calling gtk_menu_shell_select_item() on a GtkMenuBar might be the cause. Let me try to write a small test case.
Created attachment 185131 [details] Minimal GTK+ test case Yeah, I can reproduce with this code.
Created attachment 185759 [details] [review] a patch Here is a patch that seems to fix things for me. I'd appreciate some testing of this; every change to the menu code is bound to break something...
*** Bug 647512 has been marked as a duplicate of this bug. ***
The patch fixes the issue for sure (and it makes sense, but you don't need me to tell you that :-)). I won't be able to run it for long with other apps, though, so not sure my testing helps a lot...
Sorry, but I found the changes in gtkmenushellprivate.h will cause error C4013 (the GCC warning-equivilant "implicit declaration of ..." for ) _gtk_shell_activate in gtkmenuitem.c during compilation on Windows/MSVC. It seems to me reverting the changes in gtkmenushellprivate.h would not cause the problems described in this bug report for me, and that's the fix for my compilation problem-but I'm on Windows, so maybe people on Linux wants to verify things also... Thank you!
I've removed the declaration from the private header and made the function static, since it is now used in only one source file. If it is used before the definition, I've overlooked that, my apologies. Please just at a forward declaration near the top of the .c file, and keep the function static.
Hi Matthias, Committed the changes as you suggested-I hope I understood you correctly. (Commit 0098344f84cedb6347fc99691f6e3d358ec112e7) Thank you!
(In reply to comment #8) > Created an attachment (id=185759) [details] [review] > a patch > > Here is a patch that seems to fix things for me. I'd appreciate some testing of > this; every change to the menu code is bound to break something... Proposed patch solves the issue for me, thanks!
(In reply to comment #13) > Hi Matthias, > > Committed the changes as you suggested-I hope I understood you correctly. > > (Commit 0098344f84cedb6347fc99691f6e3d358ec112e7) > > Thank you! So, does it means that this bug is fixed? If this is the case, I guess that someone should close it, right?
(in reply to Comment #15) Hi Alejandro, When I committed the changes, it was to fix compilation on MSVC also, but I think that people also want to also verify that Matthias' changes could fix the root/mainproblem for this bug, so let the other people listed in this bug report see to it whether the change by Matthias works for them. So, I may not be the right guy to decide on closing this bug. Thanks though.
*** Bug 646208 has been marked as a duplicate of this bug. ***
Created attachment 341564 [details] [review] Backport Matthias Clasen's fix to GTK2 This bug is properly fixed in GTK3 since the early days of 3.0, but is still present in the GTK2 branch. It can be tested easily with Vincent Untz's test case (only needs using gtk_vbox_new() instead of gtk_box_new() for GTK2 compatibility). In the real world, it affects at least a GTK2 build of mate-panel, just like mentioned for gnome-panel in the initial comment here. The attached patch applies the fix to the GTK2 branch, merging the three commits f5eee56b56e2f371a0dc659f2d402b0cfc1c42c2, 9833fbd77a63ee5dd8f6b5519831db2a4b29ebb9 and 4eac7f24177d947852574f11ef483b1c43fd17e5 that lead to the proper, clean fix in 3.0 (the first alone is enough to fix the issue, but not totally clean). Could you please consider applying the fix to the GTK2 branch? Thanks! The code in this area doesn't seem to have changed too much either in either side, so it appears safe enough for me. Especially as the original author knows what he's doing, too :) And of course, (limited) testing shows no regression anywhere.
Any news on applying the backport to GTK2? FWIW, I and a few other are using it daily without issues. It's a fairly serious problem for applications on which it happens, especially for accessibility as this very often involves extensive keyboard navigation, which triggers this bug.
Dear all, Great thanks to Colomban and Mathias for fixing this huge issue. I confirm the bug is correctly resolved on the Colomban's GTK2 version. I have noticed any regression on my system (Debian 8.6 "Jessie") I'm a low-vision people and I confirm that the issue is really problematic. The only solution to deal with this bug for a blind user is a hard reboot. It is essential to have the patch integrated in GTK2 so that Debian accepts it. Best regards.
Hello, Ping? Any news on this? We would really like to include the gtk2 patch in Debian, but prefer to see upstream apply it to its gtk2 tree before. Samuel
Backport to GTK2 has been merged in gtk-2-24: https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=e6afe1165e2f1c74f7dbd5e6a6c965f8abcfd275