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 554057 - Calling gtk_menu_shell_select_item() on GtkMenuBar can break grabs (and create big accessibility issues)
Calling gtk_menu_shell_select_item() on GtkMenuBar can break grabs (and creat...
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkMenu
3.0.x
Other Linux
: Normal major
: ---
Assigned To: gtk-bugs
gtk-bugs
: 646208 647512 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-09-27 09:42 UTC by Tim Miao
Modified: 2017-03-23 08:52 UTC
See Also:
GNOME target: ---
GNOME version: 2.91/3.0


Attachments
Minimal GTK+ test case (1.57 KB, text/plain)
2011-04-04 18:17 UTC, Vincent Untz
  Details
a patch (1.76 KB, patch)
2011-04-11 21:43 UTC, Matthias Clasen
none Details | Review
Backport Matthias Clasen's fix to GTK2 (3.15 KB, patch)
2016-12-07 16:12 UTC, Colomban Wendling
none Details | Review

Description Tim Miao 2008-09-27 09:42:56 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.
Comment 1 Jean-François Fortin Tam 2011-03-29 18:22:44 UTC
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).
Comment 2 Joanmarie Diggs (IRC: joanie) 2011-04-04 15:25:26 UTC
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. :-(
Comment 3 Vincent Untz 2011-04-04 15:31:28 UTC
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?
Comment 4 Joanmarie Diggs (IRC: joanie) 2011-04-04 15:35:10 UTC
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
Comment 5 Javier Hernández 2011-04-04 15:43:11 UTC
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!
Comment 6 Vincent Untz 2011-04-04 18:15:23 UTC
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.
Comment 7 Vincent Untz 2011-04-04 18:17:08 UTC
Created attachment 185131 [details]
Minimal GTK+ test case

Yeah, I can reproduce with this code.
Comment 8 Matthias Clasen 2011-04-11 21:43:37 UTC
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...
Comment 9 Vincent Untz 2011-04-12 08:32:26 UTC
*** Bug 647512 has been marked as a duplicate of this bug. ***
Comment 10 Vincent Untz 2011-04-13 12:43:15 UTC
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...
Comment 11 Fan, Chun-wei 2011-04-14 16:11:47 UTC
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!
Comment 12 Matthias Clasen 2011-04-15 14:37:44 UTC
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.
Comment 13 Fan, Chun-wei 2011-04-15 16:44:35 UTC
Hi Matthias,

Committed the changes as you suggested-I hope I understood you correctly.

(Commit 0098344f84cedb6347fc99691f6e3d358ec112e7)

Thank you!
Comment 14 Javier Hernández 2011-04-19 12:09:28 UTC
(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!
Comment 15 Alejandro Piñeiro Iglesias (IRC: infapi00) 2011-04-21 14:58:40 UTC
(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?
Comment 16 Fan, Chun-wei 2011-04-21 16:08:45 UTC
(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.
Comment 17 Vincent Untz 2011-05-23 22:11:19 UTC
*** Bug 646208 has been marked as a duplicate of this bug. ***
Comment 18 Colomban Wendling 2016-12-07 16:12:21 UTC
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.
Comment 19 Colomban Wendling 2017-01-03 09:02:06 UTC
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.
Comment 20 Alex ARNAUD 2017-01-03 09:34:46 UTC
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.
Comment 21 Samuel Thibault 2017-01-11 00:08:07 UTC
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
Comment 22 Colomban Wendling 2017-03-23 08:52:26 UTC
Backport to GTK2 has been merged in gtk-2-24: https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=e6afe1165e2f1c74f7dbd5e6a6c965f8abcfd275