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 321893 - GTK+ menus eat clicks outside them
GTK+ menus eat clicks outside them
Status: RESOLVED NOTABUG
Product: gtk+
Classification: Platform
Component: Backend: Win32
2.8.x
Other Windows
: Normal enhancement
: ---
Assigned To: gtk-win32 maintainers
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2005-11-19 22:40 UTC by Jernej Simončič
Modified: 2009-07-22 20:51 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jernej Simončič 2005-11-19 22:40:09 UTC
GTK+ menus eat mouse clicks outside them when they're open - this doesn't 
happen with menus in other Windows applications. On Windows, when you open a 
menu, then click somewhere outside it, the window under the mouse button 
receives a click after the menu closes. This way, it's possible to click a menu,
 then without closing it first, drag the window away (the menu closes 
automatically).
You can easily test this even in GTK+ programs - right-click the titlebar (so 
that the window menu opens), then try moving or resizing the window without 
closing that menu first.
Comment 1 Tor Lillqvist 2005-11-20 00:52:49 UTC
I wouldn't say that the behaviour of other Windows applications is very
consistent here. I can do what you say (click once on a menu item, then move the
cursor to the title bar and start dragging the window) consistently and
repeatably in for instance Calculator and Firefox, but not in Internet Explorer
(or just an Explorer window). Hmm, in IE and Explorer (which presumably share
the same codebase) it seems that if I click on the "Favorites" menu, I can never
get it to work, but for all the other menus I can!
Comment 2 Jernej Simončič 2005-11-20 11:00:32 UTC
Confirmed about the Favorites menu, but that's an Explorer bug, since all other 
menus behave properly. I haven't encountered any other Windows application that 
would behave this way, even though I use a lot of programs that don't use the 
standard Windows menus, but instead use custom controls for them.
Comment 3 Maciej Katafiasz 2005-12-12 11:05:10 UTC
While perhaps consistency with Win32 behaviour might be desirable here, the
correct user model should IMHO be the one where clicks are eaten. That allows
you to safely close the menu by clicking *anywhere*, without the fear of
accidentally activating something. So for me, it's NOTABUG.
Comment 4 Cody Russell 2009-07-22 18:30:35 UTC
I'm agreeing with Maciej here.  But also I just think that trying to deviate from the standard GTK+ behavior for something so small is a very bad idea, so chances are that even if someone were so inspired as to write a patch for this then it would likely be rejected.
Comment 5 Jernej Simončič 2009-07-22 18:49:10 UTC
I still think it's a bug simply because it's not even consistent within GTK+ itself - the click is only eaten if you click inside the application that owns the menu - if you click elsewhere, the click isn't eaten (this is Win32-specific behaviour - on X it seems to always eat the clicks).

Also, about the Explorer's Favorites menu, I read on the Oldnewthing blog sometime ago why it eats the clicks - it's not really a menu, but a normal window that mimics one.
Comment 6 Owen Taylor 2009-07-22 20:51:15 UTC
Considering the gymnastics that win32 GTK+ goes through in this area to try and sort of duplicate the X11 behavior, I'd tend to think a focus-only mode for GtkMenu that didn't use grabs could be a pretty nice contribution.